Home

TriMed’s Patient Data API offers the ability to securely access patient data stored in the TriMed EHR for a specific patient. The API requires each developer to work with the practice(s) leveraging the TriMed EHR to obtain access. See Authentication section for details. All developers must agree to the Terms and Conditions listed on this site.

Once Authentication details have been obtained, developers may call the TriMed Patient Data API using normal web methods. Outlined below is the standard order of operations in order to navigate the API:

1. Lookup Patient:

A developer invokes the LookupPatientID method in order to determine the presence of the patient in the TriMed EHR for the practice. If a matching patient is found, a unique LookupPatientID will be returned. This represents the unique patient identifier used in all the other API methods.

2. Get Patient Data:

Using the unique patient identifier obtained in step 1, the developer now invokes a method to retrieve the patient data represented by the unique patient identifier. The Get Patient Data method returns all the patient data available for a patient in a single response. All other methods are subsets of the Get Patient Data method designed to only return a specific piece of the identified patient’s records.

Developer workflow

TriMed’s Patient Data API exists as a web based API written in SOAP format. For more about SOAP format, see here. No special software is necessary to access the public facing web methods available in the TriMed Patient Data API. Example screenshots are offered below using the basic Postman tool (to download Postman click here).

TriMed’s Patient Data API is available at:

https://svcs-ccd.trimed.cloud/PatientAPI.asmx

Step 1: Forming the Lookup PatientID Method.

Note: The below examples assume the developer has obtained an authentication code from the practice. Authentication codes can be generated by the practice within the TriMed EHR.

Here is an example REQUEST method for the LookupPatientID method as shown in Postman:

1. The Patient API URL is placed in the URL area and the ‘POST’ verb is chosen

2. The XML method goes in the Body

a. The method name should open the XML body: <LookupPatientId xmlns="http://tempuri.org/">
b. The Authentication Key should be placed in the sAuthKey parameter
c. The Practice Enterprise should be placed in the lEnterpriseID parameter
d. The Practice Company should be placed in the lCompanyID parameter
e. The Patient Information should be passed in the respoective Patient parameters
f. The method name should close the XML body:</LookupPatientId>

3. Send the Request to the URL using the Send button

For further details on forming the XML Body, see the Lookup PatientId page.

Here is an example RESPONSE method for the LookupPatientID method as shown in Postman:

Step 2: Forming the Patient Data Method

Note: The below examples assume the developer has successfully retrieved a PatientID using the LookupPatientID method. The PatientID will be passed into the GetPatientData method.

Here is an example REQUEST method for the GetPatientData method as shown in Postman:

1. The Patient API URL is placed in the URL area and the ‘POST’ verb is chosen.

2. The XML method goes in the Body

a. The method name should be open the XML body: <GetPatientData xmlns="http://tempuri.org/">
b. The Authentication key should be placed in the sAuthKey parameter.
c. The Practice Enterprise should be placed in the lEnterpriseID parameter
d. The Practice Company should be placed in the lCompanyID parameter
e. The PatientID should be passed in the lPatientID parameter
f. Your application name should be passed in the SRequestFrom parameter
g. For each of the data types, pass a ‘true’ or ‘false’ to return that data type in the respective boolean parameters (e.g., passing ‘true’ into the SPatientName parameter will return the patient name in the response).
h. Pass the number of days from the current date into the lRelativeDays parameter to restrict the data returned by the respective number of days.
i. The method name should close the XML body: </GetPatientData>

3. Send the Request to the URL using the Send button.

For further details on forming the XML Body, see the Patient Data page.

Here is an example RESPONSE method for the GetPatientData method as shown in Postman:

Step 3: Forming Other Patient Data Methods

Note: The below examples assume the developer has successfully retrieved a PatientID using the LookupPatientID method. The PatientID will be passed into the GetPatientAllergy method.

Here is an example REQUEST method for the GetPatientAllergy method as shown in Postman:

1. The Patient API URL is placed in the URL area and the ‘POST’ verb is chosen.

2. The XML method goes in the Body

a. The method name should be open the XML body: <GetPatientAllergy xmlns="http://tempuri.org/">
b. The Authentication key should be placed in the sAuthKey parameter.
c. The Practice Enterprise should be placed in the lEnterpriseID parameter
d. The Practice Company should be placed in the lCompanyID parameter
e. The PatientID should be passed in the lPatientID parameter
f. Your application name should be passed in the SRequestFrom parameter
g. The method name should close the XML body: </GetPatientAllergy>

3. Send the Request to the URL using the Send button.

For further details on forming the XML Body, see the Patient Allergy page.

Here is an example RESPONSE method for the GetPatientAllergy method as shown in Postman:

Parameter	Type	Required	Description
sAuthKey	string	Yes	The secret key generated by the practice to give access to the developers
IEnterpriseID	long	Yes	The practice enterprise ID
ICompanyID	long	Yes	The practice company ID
PatientLast	string	Yes	The patient’s last name
PatientFirst	string	Yes	The Patient’s first name
PatientGender	string	Yes	The patient’s sex M/F
PatientDOB	date	Yes	The patient’s date of birth (mm/dd/yyyy)
ResponseCode	number	No	The response code
Message	string	No	The message details from the webmethod if there is any

Code	Meaning
100	The request was processed appropriately
101	Authentication key expired
102	Authentication key invalid
103	Invalid parameters
104	Invalid date format

Code	Meaning
100	The request was processed appropriately
101	Authentication key expired
102	Authentication key invalid
103	Invalid parameters
104	Invalid date format

Parameter	Type	Description
Encounters
Encounter	string	Text description of encounter type (‘Established Patient Sick’, (‘18 Year Well Established’)
Performer-Care Team	string	FerrugioCare Provider Name (‘Dr. Adam Racoon’, ‘Dr. Rachel Warren’)
Location	string	Encounter Address (‘123 Main Street, High Point, NC 27265’)
Date	string	Encounter Date (‘mm/dd/yyyy’)
Encounter Diagnosis	string	Encounter Diagnosis (Snomed term) See this resource to reference Snomed terms
Allergies
Allergy Name	string	Name of the allergy (e.g., ‘milk’, ‘amoxicillin’ )
Reaction	string	Allergic reactions (e.g., ‘itching’, ‘hives’)
Severity	string	Text description of severity level (‘Normal’, ‘Severe’)
Timing Information	string	Allergy recorded datetime (date format = ‘mm/dd/yyyy’)
Concern Status	string	Allergy Status (e.g., ‘Current’, ‘Historic’)
Problem List
Problem Name	string	Text description of patient problem
CodeDescription	string	Snomed term for patient problem See this resource to reference Snomed terms
Concern Status	string	Problem status (e.g., ‘Current’, ‘Historic’, ‘Resolved’, etc)
Timing Information	string	Onset Date (‘mm/dd/yyyy’)
Medications
Medication	string	Text Description of Drug Name
Strength	string	Drug Strength (e.g., ‘5mg’, ‘200mg/5mL’)
Route	string	Dose Route (e.g., ‘Oral’, ‘Injection’)
Dose/Frequency	string	Dose Frequency (e.g., ‘Daily’, ‘3 times per day’)
Timing Information	string	Date Medication Prescribed (‘mm/dd/yyyy’)
Immunizations
Vaccine	string	Text Description of Immunization
Date	string	Date Immunization Administered (‘mm/dd/yyyy’)
Status	string	Immunization administration status (e.g., ‘Given’, ‘Not Given’)
Manufacturer	string	Immunization manufacturer name
LotNum	string	Immunization lot number
Note	string	Comments on immunization administered status (e.g. ‘Not given due to patient allergy’)
Lab Results
Test Code/LOINC	string	Test Code (LOINC code) See this resource to reference Loinc terms
Description	string	Text description of lab result (‘White Blood Cell Count (WBC)’, ‘Red Blood Cell Count (RBC)’
Value	string	Result value for lab result (e.g., ‘6.9’,’6.5’)
Units	string	Result value for lab result (e.g. ‘K/mcL’, ‘g/dL’)
Flag	string	Result Value Flag (e.g. ‘High’, ‘Low’, ‘Normal’)
Range	string	Result Value Range (e.g. ‘4.8-10.8’, ‘14.0-18.0’)
Date Performed	string	Result Observation Date (‘mm/dd/yyyy’)
Vitals
Vitals Name	string	Text description of vital measurement
Timing Information	string	Date of vital measurement
Value and Units	string	Value and units of vital measurement (‘60 inches’, ‘200 pounds’)

Parameter	Type	Required	Description
sAuthKey	string	Yes	The secret key generated by the practice to give access to the developers
IEnterpriseID	long	Yes	The practice enterprise ID
ICompanyID	long	Yes	The practice company ID
lPatientID	long	Yes	The patient’s unique ID number
sRequestFrom	string	No	The developer application name which calls this method
dStartDate	date	No	Allergies with a status date greater than or equal to the entered Start Date will be returned (format = 'mm/dd/yyyy', e.g. 12/30/1990)
dEndDate	date	No	Allergies with a status date less than or equal to the entered End Date will be returned (format = 'mm/dd/yyyy', e.g. 12/30/1990)
ResponseCode	number	No	The response code
Message	string	No	The message details from the webmethod if there is any

Home

1. Lookup Patient:

2. Get Patient Data:

Developer workflow

Step 1: Forming the Lookup PatientID Method.

Step 2: Forming the Patient Data Method

Step 3: Forming Other Patient Data Methods

Terms of Use (TriMed Patient Data API version 1.3)

1. OFFICE OF THE NATIONAL COORDINATOR FOR HEALTH INFORMATION TECHNOLOGY (“ONC”)

2. ACCEPTING THE TERMS

a. Legal Age

b. Entity Level Acceptance

3. CHANGES

a. Changes To TRIMED API

b. Changes To TRIMED API Terms of Use

4. RESPONSIBILITIES AND REPRESENTATIONS

a. Compliance

b. Registeration

c. Privacy Policy

5. MEDICAL PRACTICE

6. TRIMED API RESTRICTIONS

7. TRIMED API LIMITATIONS

8. IP OWNERSHIP

9. INDEMNIFICATION

10. DISCLAIMERS

11. LIMITATION OF LIABILITY

12. THIRD PARTY CONTENT

13. TERM AND TERMINATION

14. PUBLICITY

15. APPLICABLE LAW

Authentication

Authentication Overview:

Key Security:

A secure authentication key contains a combination of four unique characteristics:

Key Generation:

1. Developer requests key from Practice:

2. Practice generates key for Developer:

LookupPatientId

Post

Sample Request

Request Parameters

Response Codes

Response Parameters

Sample Response

Underlying SQL (Internal Use Only)

GetPatientData

Post

Sample Request

Request Parameters

Response Codes

Response Parameters

Item Grouping

Sample Response

GetPatientAllergy

Post

Sample Request

Request Parameters

Response Codes

Response Parameters

Sample Response

Underlying SQL (Internal Use Only)

GetPatientProblemList

Post

Sample Request

Request Parameters

Response Codes

Response Parameters

Sample Response

Underlying SQL (Internal Use Only)

GetPatientMedication

Post

Sample Request

Request Parameters

Response Codes

Response Parameters

Sample Response

Underlying SQL (Internal Use Only)

GetPatientImmunization

Post

Sample Request