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: | ||||||
| ||||||
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. |
Class | Description | |
---|---|---|
Api |
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.
| |
CCDASectionFilter |
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.
| |
Database |
The Database resource focuses about the database the user can access
| |
DatabaseAlreadySetException |
Thrown when calling Api.SetDatabase when there is already a database set
| |
Encounter |
The Encounter resource focuses on basic data relating to a visit.
| |
IniFileNotFoundException |
Thrown when logging in if the ThomasEmr.ini file can not be found
| |
LoginResult |
The LoginResult resource focuses on information on the result of the login process
| |
NotLoggedInException |
Thrown when trying to search for patients before logging in
| |
Patient |
The Patient resource focuses on demographic information.
|