Click or drag to resize
ehrThomas

ehrApi Namespace

Introduction
Genius Solutions Inc. has created a set of APIs (Application Programming Interface) to provide third party software developers who are developing software applications for accessing Protected Health Information (PHI) of patients on ehrTHOMAS. This set of APIs is collectively called the ehrApi.
This document contains the information necessary for applications to access ehrTHOMAS via ehrApi. The intended purpose satisfies the requirements of 2015 CEHRT Regulations § 170.315(g)(7) and § 170.315(g)(9) in order to achieve patient matching and access to the USCDI.
Within ehrApi documentation sections, you will find links which provide: API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.
Terms and Conditions of Use
ehrApi online documentation and its library files have been made available to developers for development and testing. The materials are provided to developers as-is with no other warranties expressed or implied. Developers may use the materials with adherence to the below terms and conditions:
1.ehrApi online documentation has the most up-to-date information. Developers may keep copies of the materials; but, may not distribute a copy of the materials. Developers wishing to share the materials may do so via linking other developers to the materials hosted by Genius Solutions Inc.
2.Developers are responsible for the products developed and how the products connect to the client's server and ehrTHOMAS application. Developers are also responsible for complying with all applicable laws, including not infringing Genius Solutions Inc and its ehrTHOMAS' intellectual property rights.
3.This ehrApi provides protected health information of patients within ehrTHOMAS application and therefore must be used securely. The developer is entirely responsible for all content that is requested via the ehrApi. If you are using the ehrApi on behalf of your employer, you represent and warrant that you are authorized to accept these Terms on your employer's behalf, and that your employer agrees to indemnify Genius Solutions Inc. and its ehrTHOMAS for violation of these Terms.
Security and Authentication
Accessing a patient PHI requires both database and per-patient authentications. The patient must communication with the data owner office (the physician) and the third party vendor. It is between the data owner and the third party vendor to choose a delivery method for database access and patient token.
Database Access
Developers will need to obtain a security clearance, server and database access information from the data owner in order to gain access to the database and utilize ehrApi to request data. It is recommended that the data owner creates a new ehrTHOMAS login access for developers to use in order to track developers activities while connecting to the database.
Patient Authorized Token
Any patient who wishes to allow and share their PHI with the third party vendors must contact the data owner to authorize the office to generate a patient authentication token with an expiration date.
Once the developer receive the proper access and authentication token, and download all required components, the developer should be able to access and gather patient data accordingly. The data owner can also monitor the third party vendor access through the audit log.
Install Package
Developers must download ehrApi .NET client library in order to develop their applications for accessing PHI on ehrTHOMAS. Download here
Data Access Information
With a proper access and authentication, ehrAPI allows the developers to pass calls and returns a complete CCDA for a single patient based on the patient token. Date parameters can be used to filter the data to either a range of days or a single day. CCDASectionFilter parameters allow the developer to filter CCDA object. By default, all CCDA sections will be returned when searching for the patient’s data. When calling for a patient, ehrAPI will return the patient basic demographic as a set by default. The basic patient demographic includes: patientID, tokenID being used, account number, first name, middle name, last name, DOB and gender along with encounter dates and encounterIDs. Extended patient demographic information such as address, contact info, race, ethnicity, language will be returned with encounter CCDA object. The result of CCDA object being passed back will always include the complete patient demographic (Patient’s first name, middle name, last name, patientID, tokenID, DOB, gender, contact info, race, ethnicity, and language). If all CCDA sections are filtered out, the end result of CCDA object will only return the complete patient demographic with EMR location where data being generated, no other info will be passed back.
Classes
  ClassDescription
Public classApi
An Api for exporting patient data from ehrThomas. With a proper access and authentication, ehrAPI allows the developers to pass calls and returns a complete CCDA for a single patient encounter based on the patient token. Date parameters can be used to filter the data to either a range of days or a single day. CCDASectionFilter parameters allow the developer to filter CCDA object. By default, all CCDA sections will be returned when searching for the patient’s data. When calling for a patient, ehrAPI will return the patient basic demographic as a set by default. The basic patient demographic includes: patientID, tokenID being used, account number, first name, middle name, last name, DOB and gender along with encounter dates and encounterIDs. The complete patient demographic information (Patient’s first name, middle name, last name, patientID, tokenID, DOB, gender, contact info, race, ethnicity, and language) will be returned with encounter CCDA object. The result of CCDA object being passed back will always include the complete patient demographic (Patient’s first name, middle name, last name, patientID, tokenID, DOB, gender, contact info, race, ethnicity, and language). If all CCDA sections are filtered out, the end result of CCDA object will only return the complete patient demographic with EMR location where data being generated, no other info will be passed back.
Public classCCDASectionFilter
CCDASectionFilter parameters allow the developer To filter a CCDA Object. By Default, all CCDA sections will be returned. When searching for the patient's data. The complete patient demographic information (Patient’s first name, middle name, last name, patientID, tokenID, DOB, gender, contact info, race, ethnicity, and language) will be returned with encounter CCDA object.

  • By default, the complete patient demographic information (Patient's first name, middle name, last name, patientID, tokenID, DOB, gender, contact info, race, ethnicity, and language) will be returned with ALL encounter CCDA sections.
  • If all parameters are filtered out (as false), the end result of CCDA object will only return the complete patient demographic with EMR location where data being generated, no other info will be passed back.
  • If only one CCDA parameter (data section) Is called (as true), the end result of CCDA object will return the complete patient demographic along with the data of the selected section. Example: If a medications parameter Is the only one that Is called, the result will be CCDA Object containing the complete patient demographic follows by CCDA medication section.
  • If 2 Or more CCDA parameters are called (as true), the end result of CCDA object will return complete patient demographic along with data of the selected sections. Example: If the medications, allergies, And results parameter are called, the result will be CCDA Object containing the complete patient demographic follows by CCDA medications, allergies, And results sections.
Public classDatabase
The Database resource focuses about the database the user can access
Public classDatabaseAlreadySetException
Thrown when calling Api.SetDatabase when there is already a database set
Public classEncounter
The Encounter resource focuses on basic data relating to a visit.
Public classIniFileNotFoundException
Thrown when logging in if the ThomasEmr.ini file can not be found
Public classLoginResult
The LoginResult resource focuses on information on the result of the login process
Public classNotLoggedInException
Thrown when trying to search for patients before logging in
Public classPatient
The Patient resource focuses on demographic information.