Looking to Join Healthix?

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 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 >

Healthix Alerts 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 Alerts 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 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 >

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.

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.

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.

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 >

As a QE, Healthix receives public funding from New York State to provide a variety of core technology services to its Participants as part of the Statewide Health Information Network of New York (SHIN-NY). QEs must use these funds to provide a minimum set of services to their members, at no charge. Healthix does not collect annual member fees from its Participants.

QEs are permitted to offer additional services as “value added” services to their members for which they may collect a fee. New York State QEs are required to provide this disclosure to prospective QE participants, and upon request at any time.

To obtain a Healthix Fee schedule, contact us at [email protected] If you’d like to know more about the value-added services offered by the RHIO, contact us at [email protected], call 1-877-695-4749 or contact your Healthix Account Manager.