Open API Framework
The ezEMRx Open API documentation provides information for searching and fetching patient data from the Common Clinical Data Set as defined by the Meaningful Use 3 2015 regulations. Data search and read are the only interactions currently supported. The search criteria are intended to meet the 2015 Edition ONC Certification criterion Patient Selection 170.315(g)(7), Category Search 170.315(g)(8) and All Category Search 170.315(g)(9). Access is based on the HL7 FHIR Data Access Framework (DAF) profile and draws requirements from DSTU2. Generally, only required DSTU2 data elements are provided.
ezEMRx Open API service uses the restful based service architecture which allows seamless integration over the HTTPS protocol. This means that any client that can communicate over HTTPS can easily communicate with the ezEMRx Open API service. This allows any client request to communicate with the ezEMRx Open API service as the call to the operation essentially entails the building of a URL string to call an operation in the service. Data passed to the operation is supported in JSON. Upon registering, you will have access to ezEMRx API documentation.
ezEMRx's OpenID registration is available for FHIR API-based connectivity to healthcare organizations using ezEMRx. ezEMRx customers are third-party beneficiaries under these Terms and Conditions. You will be able to connect to ezEMRx Customers who have chosen to allow access with APIs for this purpose.
ezEMRx will issue a unique client identifier to keep track of the use of ezEMRx's FHIR APIs. ezEMRx or its customers might suspend or revoke a client identifier at its discretion at any time as a result of a non-conformance. If this happens, you will not be able to communicate with ezEMRx's Customers until the non-conformance is resolved. You may contact ezEMRx Support on resolving the problem that led to the client identifier being suspended.
Direct access to ezEMRx is not required to develop or test your products. Testing can be done via the ezEMRx sandbox. Your access to ezEMRx documentation does not give you permission to access ezEMRx, and does not give you permission to access ezEMRx Customer's. Your access to ezEMRx is only be granted by ezEMRx. You must follow the ezEMRx FHIR Guidelines, including compliance to the ONC Certification Criteria.
Terms of Use
Your use of this site, including, without limitation, accessing/registering the ezEMRx APIs and the ezEMRx API Sandbox, is subject to these ezEMRx API Terms of Use. ezEMRx may update and modify the ezEMRx API Terms of Use at its sole discretion and without notice. API Developers and other users of this site should regularly check this site for updates to the ezEMRx API Terms of Use.
Ownership
ezEMRx retains all ownership of ezEMRx property and reserves all of its applicable rights with respect to the content of this site, ezEMRx EHR and ezEMRx APIs. Nothing in the ezEMRx API Terms of Use or any documentation associated with the ezEMRx APIs is intended to convey any transfer of ownership of ezEMRx's property.
Source Code or Software
ezEMRx API Developers may test applications by using the ezEMRx API Sandbox or by collaborating with the ezEMRx EHR; it is not necessary to access the ezEMRx EHR to test applications. In connection with providing the ezEMRx APIs, ezEMRx does not offer a license to use the ezEMRx EHR, or access to the ezEMRx EHR to any party that has not purchased a license to the ezEMRx EHR. ezEMRx will not make any ezEMRx source code available to any party in connection with the ezEMRx APIs.
Indemnity
By accessing/registering the ezEMRx APIs and ezEMRx API Sandbox, you assume the risk of liability for, and agree to indemnify and hold harmless ezEMRx and its affiliates, employees, customers, partners, dealers (collectively, the "ezEMRx") and will defend ezEMRx from and against any and all liabilities, losses, claims, damages, claims and expenses (including legal expenses of any kind and nature) arising out of, or relating to, directly or indirectly: (a) any action or omission related to (i) your use of the ezEMRx APIs or (ii) the development, content, or performance of third party applications developed by you or (b) your failure to comply with any federal, state or local laws, rules or regulations in connection with your use of the ezEMRx APIs.
Warranty Disclaimers
ezEMRx APIs and ezEMRx API Sandbox are provided on an "as-is" basis with all faults and defects, and without any warranty whatsoever. The entire risk as to the quality and performance of the ezEMRx APIs is with the third party Developer. ezEMRx shall be responsible for the performance of ezEMRx developed applications. ezEMRx does not provide any service level agreements or performance objectives for availability, response time or any other performance measurement associated with the ezEMRx APIs or the ezEMRx Sandbox. For any issues alleged to be caused solely by the ezEMRx APIs or the ezEMRx API Sandbox, API Users may report issues to ezEMRx at This email address is being protected from spambots. You need JavaScript enabled to view it.. ezEMRx will make reasonable efforts to investigate and correct such issues at its sole discretion towards the functioning of the ezEMRx API as intended.
Introduction
Fast Healthcare Interoperability Resources, or FHIR, is a standard way of defining an API for healthcare resources. More information can be found at the https://www.hl7.org/fhir/. The ezEMRx FHIR API is based on DSTU 2 of the FHIR standard. The ezEMRx FHIR API is a RESTful implementation for an API. FHIR is resource-based.
The resources are healthcare or related resources, such as patient, problems, immunizations or medications. These resources are accessed through HTTP to retrieve a resource with a GET. To update a resource a POST is performed. ezEMRx FHIR API uses OAuth 2 for security. This means that when making calls to an ezEMRx resource, you must pass a token. This token must be passed in the Authorization Header.
- Initially a call must be made to ezEMRx's FHIR Authorization Server at https://fhir.ezemrx.com/authorization/connect/authorize. The authorization server will confirm the user's credentials.
- To obtain a token, a call must be made to ezEMRx's FHIR Authorization Server at https://fhir.ezemrx.com/authorization/connect/token.
The ezEMRx FHIR API supports JSON and confidential clients.
Using a refresh token
To prevent a user from having to log in whenever the access token expires, use a refresh token. The refresh token will be valid for hours/days. To get a new access token, call the token endpoint of the authorization server and present your bearer token. If the bearer token has expired, you must call the authorization endpoint of the authorization server again so the user can login using their credentials.
Authorization for patient access
ezEMRx's API calls are patient specific. The following authorization rules apply: If the user is a patient:
- Have access to their own data.
- Have access to patients for whom they are caregivers or guardian.
- No access to the data for any other patients.
If the user is a provider or other EHR user:
- Have access to patients they are authorized to see in their EHR.
- No access to patients they are not authorized to see in their EHR.
- No access to the "break glass" functionality.
Requesting Access
Step 1: Signup for a client account and register the app
If you have not already completed this step, follow the instructions at https://hie.ezemrx.com/ezEMRxHIE/oauth2/ for Signup and Registration. After the registration, you should have the following:
- ClientId
- Secret
- redirect_uri - This is the URL where the application will reside once authorization is completed.
Step 2: Obtain a Bearer token
You must use the OAuth 2.0 authorization client that is built into the framework you are using. Your OAuth 2.0 authorization client issues a request similar to the following:
https://fhir.ezemrx.com/authorization/connect/authorize?response_type=code&client_id=<your ClientID>&redirect_uri=<your redirect_uri>&scope=launch%20openid%20profile
The Authorization Server will request your credentials. Use you username and password. The OAuth 2.0 authorization client will next issue a request to the token endpoint to get the authorization token. Enter the secret that was provided earlier. The authorization token now can be used in subsequent calls. Call the authorization server to get a bearer token. The authorization server returns a JSON structure:
{
"access_token" :111.222.3333
"expires_in": 1800,
"token_type": "Bearer"
......
The authorization token is is a JSON Web Token (JWT). It uses the format: nnn.nn.nnnn. Bearer tokens are valid for 30 minutes. If the bearer token expires, you must refresh it.
Step 3: Retrieving information
To retrieve information for the patient with ID 1501, issue the following
GET request: https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/1501
Authorization: Bearer 111.222.3333
The Bearer token is retrieved in the previous step. It is used in the authorization header. This returns the requested patient information.
API - Endpoints
API Name |
API Endpoint URL |
Patient Search | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient?name=Jane |
Retrieve Patient | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id |
Problem | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/Condition |
Immunization | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/Immunization |
Medication | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/Medication |
Allergy | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/Allergy |
SocialHistory | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/SocialHistory |
LabResults | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/LabResults |
Vitals | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/Vitals |
Procedure | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/Procedure |
CarePlan | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/CarePlan |
Goals | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/Goals |
Device | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/Device |
DocumentReference | GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient/id/DocumentReference |
ezEMRx OAuth Architecture
Searching for a patient
GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient?name=Jane
GET https://services.ezemrx.com/ezEMRx/ezFHIR/Patient?given=Jane&gender=female The following parameters can be specified in the search query:
Name | Description |
name | Portion of either the last or first name of the patient. |
_id | ID of the patient. |
family | Portion of the last name of the patient. |
given | Portion of the first name of the patient. |
gender | Patient's gender. For more information on this value set, see https://www.hl7.org/fhir/valueset-administrative-gender.html |
birthdate | Patient's date of birth. For more information on this type, see https://www.hl7.org/fhir/datatypes.html#date |
Searching using a patient ID
A patient ID should be used to query for additional information. The search function is described above. If the response returns one or more patients, the response contains the PID (or patient IDs).
{ "resourceType": "Bundle", "type": "searchset", "entry":[ { "resource":{"resourceType": "Patient", "id":"1501", "language": "", "text":{"status": "generated",...} } ]}
You can now use the PID in subsequent requests.
Querying and retrieving a patient
The patient's PID used to retrieve the patient is passed as part of the URL.
GET https://services.ezemrx.com /ezEMRx/ezFHIR /Patient/id
Name | Description |
id | Patient's PID. This is retrieved using the search function. |
<pstyle="text-align: center;">
A Patient record is returned on the query using the PID. The following table describes the information returned.
Name | Description |
identifier | Patient's PID. Patients are usually assigned a specific numerical identifier that is unique within the system. |
active | Is the patient's record active? The default value is true. Need to be able to mark a patient record as not to be used because it was created in error. If a record is inactive, and linked to an active record, then future patient/record updates should occur on the other patient. |
name | Name associated with the patient. |
telecom | Patient contact communication detail. This indicates the value in any kind of telecom details field for the patient. If capturing a phone, fax, or similar contact point, the value is a properly formatted telephone number according to ITU-T E.123. However, this is frequently not possible due to legacy data and/or clerical practices when recording contact details. For this reason, phone, fax, page, and email addresses are not handled as formal URLs. |
gender | Patient's gender. Returns Male, Female, Other, or Unknown. Patient's gender. For more information on this value set, see https://www.hl7.org/fhir/valueset-administrative-gender.html |
birthDate | Patient's date of birth. This indicates a specific calendar date or partial date (either a year or a month and year combination). Time zone is not included. Fuzzy (approximate) dates are not valid. |
deceasedBoolean | Is the patient deceased? If a patient is deceased, it influences the clinical process and human communication. If this value is blank, most systems interpret the missing information as an indication that the patient is alive. |
address | Patient's postal address. Postal addresses are often used to record a location that can be visited to find a patient or person. |
maritalStatus | Patient marital (civil) status. For more information on this value set, see https://www.hl7.org/fhir/valueset-marital-status.html |
The json response is similar to the following:
Qualifying searches by date
Dates are passed as parameters on the URL. Comparators (>, <=) are not supported and these are passed in as part of the date as shown below.
date=eq2018-01-01
date=gt2018-01-01 The following comparators are supported:
Comparator | Description |
eq | equal |
gt | greater than |
ge | greater than or equal |
lt | less than |
le | less than or equal |
To search for a date range, pass in the date twice as - date=ge2010-01-01&date=le2010-12-31
Querying and retrieving a patient's problems
The patient's PID used to retrieve the patient is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Condition
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Condition?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's problems or diagnosis are returned. The following table describes the information returned.
Name | Description |
identifier | External ID for the condition. The ID is defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate. For example, in CDA documents or in written or printed documentation. This may include ICD10/Snomed. |
Status | Clinical Status. Valid entries include Active, Resolved |
Patient | Patient ID. This indicates the patient who the condition record is associated with. This is used for querying and retrieving patient demographic information. |
Code | ID of the condition, problem, or diagnosis. The value set includes content from SNOMED. |
Category | Condition Category. Option include Complaint, Symptom, Finding, Diagnosis |
OnsetDateTime | Date recorded when the condition / problem was noted by the patient. |
Querying and retrieving a patient's immunizations
The logical ID of the patient to retrieve is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Immunization
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Immunization?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's immunizations are returned. The following table describes the information returned.
Name | Description |
identifier | Immunization record unique identifier. |
status | Immunization current status. Valid entries include: In-Progress, On-Hold, Completed, Entered-In-Error, and Stopped. For more information on this value set, see medication-admin-status. |
date | Date and time when the immunization was administered. When immunizations are patient reported, a specific date might not be known. Although partial dates are allowed, an adult patient might not be able to recall the year a childhood immunization was given. |
vaccineCode | Vaccine product administered. Values come from vaccine-code. |
patient | Patient who received the immunization. Defines constraints and extensions on the patient resource for use in querying and retrieving patient demographic information. |
wasNotGiven | Flag for whether immunization was given. |
reported | Is this a self-reported record? |
performer | Who administered vaccine. |
requester | Who ordered vaccination. |
encounter | Encounter administered as part of. |
manufacturer | Vaccine manufacturer. |
location | Where vaccination occurred. |
lotNumber | Vaccine lot number. |
expirationDate | Vaccine expiration date. |
site | Body site where the vaccine was administered. |
route | How the vaccine entered the body. |
doseQuantity | Amount of vaccine administered. |
note | Vaccination notes. |
explanation | Administration/non-administration reasons. |
- explanation.reason | Reason why the immunization occurred. |
reaction | Details of a reaction that followed the immunization. |
- reaction.date | Date/time when the reaction started. |
- reaction.detail | Additional information about the reaction. |
- reaction.reported | Was the reaction self-reported? |
vaccinationProtocol | Protocol that was followed during the administration of the immunization. |
- vaccinationProtocol.doseSequence | Dose number within the series. |
- vaccinationProtocol.description | Details of vaccine protocol. |
- vaccinationProtocol.authority | Individual who is responsible for the immunization protocol. |
- vaccinationProtocol.series | Name of vaccine series. |
- vaccinationProtocol.seriesDoses | Recommended number of doses for immunity. |
- vaccinationProtocol.targetDisease | Disease immunized against. |
- vaccinationProtocol.doseStatus | Indicates if the dose counts towards immunity. |
- vaccinationProtocol.doseStatusReason | Why dose does (not) count. |
Querying and retrieving Patient's Goals
The patient's PID is used to retrieve is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Goals
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Goals?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's FHIR Goal is returned. The following table describes the information returned.
Name | Description |
identifier | External ID for this goal. This is a business identifier, not a resource identifier. This records identifiers associated with this care plan that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate (for example, in CDA documents, or in written/printed documentation). |
Subject | Who the goal is intended for. Subject identifies the patient, group, or organization for whom the goal is being established, typically the patient. Subject is optional to support anonymized reporting. |
Description | Desired outcome. This is a human-readable description of a specific desired objective of care. Without a description of what's trying to be achieved, the element has no purpose. |
status | Indicates whether the goal has been reached and is still considered relevant. Options include: Proposed, Planned, Accepted, Rejected, In-progress, Achieved, Sustaining, On-hold, and Cancelled. For more information on this value set |
Querying and retrieving Patient's Implantable devices/UDI
The patient's PID is used to retrieve is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Device
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Device?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's implantable device is returned. The following table describes the information returned.
Name | Description |
identifier | Unique instance identifier assigned to a device by organizations like manufacturers or owners. If the identifier indicates the type of device, Device.type should be used. This is a business identifier, not a resource identifier, often fixed to the device as a barcode, and may include names given to the device in local usage. Note that some of the barcodes affixed to the device identify its type, not its instance. For the FDA mandated Unique Device Identifier (UDI), use the Device.udi element |
Manufacturer | Name of the device manufacturer |
Model | Model Number assigned by the manufacturer |
Version | Version Number |
Manufacturer Date | Date of manufacture |
Expiry Date | Date of Expiry |
UDI | FDA mandated Unique device identifier |
Lot Number | Manufacturer assigned lot number |
Owner | Organization responsible for device |
Patient | If the resource is affixed to the patient. |
Querying and retrieving Patient's Smoking Status
The patient's PID is used to retrieve is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/SocialHistory
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/SocialHistory?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's smoking status is returned. The following table describes the information returned.
Name | Description |
identifier | Observation's unique ID. This applies to the instance observation |
Status | Observation Status |
Code | Smoking Status. Status of the individual patient results. For more details refer Smoking status value set |
Subject | The Patient's whose characteristics are identified by this observation |
Encounter | The encounter where this was documented |
Effective Date and Time | The observation that been captured date and time |
Performer | Person responsible for this observation |
Comments | Comments regarding the identified observations |
Querying and retrieving Patient's Procedure
The patient's PID is used to retrieve is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Procedure
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Procedure?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's procedure is returned. The following table describes the information returned.
Name | Description |
identifier | Procedure Identifier. These identifiers are defined by business process |
Subject | The person on which the procedure was performed |
Status | Status of the procedure, (In-Progress, Completed). For more details refer procedure-status |
Code | Identification code for the procedure. The value set defines a set of codes that can be used to indicate the type of the procedure; a specific code that indicates the procedure performed from SNOMED-CT, ICD 10- CPY etc. |
Performer | Person who performed this procedure |
Performed Date and Time | The procedure performed date and time |
Querying and retrieving Patient's Allergy
The patient's PID is used to retrieve is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Allergy
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Allergy?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's allergy is returned. The following table describes the information returned.
Name | Description |
identifier | Identifier that are listed with allergy are defined by the business processes |
Onset | Date and Time of the onset of the allergy or intolerance identified |
Recordeddate | Date when the Allergy was recorded |
Recorder | Person who recorded the allergy or the allergy intolerance and takes ownership for its content. Options include 'Provider' or 'Patient' |
Reporter | Source of the Information about the allergy. Options include 'Provider' or 'Patient' |
Status | Status of the identified allergy or intolerance. The status code will be taken from the AllergyIntoleranceStatus value set and the option include 'Active', 'Inactive' |
Category | Category if the allergy. Option include 'Food', 'Drug', Other'. For more details, refer the value set http://hl7.org/fhir/Valueset/allergy-intolerance-category |
Reaction | Details regarding each adverse reaction event linked to the exposure to the identified allergy or intolerance |
Onset | Date and time the reaction was showed |
Severity | Severity of the reaction or the event. Option include 'Mild' / 'Moderate' or 'Severe' |
Querying and retrieving Patient's Medication
The patient's PID is used to retrieve is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Medication
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Medication?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's medication is returned. The following table describes the information returned.
Name | Description |
identifier | Identifier that are listed with allergy are defined by the business processes |
Status | Medication Status. Option include 'Active', 'Completed'. For more information on this value set, see medication-order-status. |
Code | Medication being administered or to be taken. For more details, Refer the RxNorm code set (http://www.nlm.nih.gov/research/umls/rxnorm) |
Isbrand | Indicated if the medication is a brand name |
Manufacturer | Manufacturer of the medication |
Product | Product form option include 'Tablet /Capsule' etc. |
Batch | Batch / Lot number |
ExpirationDate | Expiry date of the medication |
package | Description of the type of packaging |
Querying and retrieving Patient's Lab Results
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/LabResults
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/LabResults?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's Lab Results is returned. The following table describes the information returned.
Name | Description |
identifier | Unique Identifier for the observation instance. External ID - is for the Lab vendor to send the results such that this ID that they send |
Status | Status of the result value or codes providing the status of the observation. The option includes, 'Final', Preliminary', 'Cancelled' etc. |
Category | Fixed Category coding system that includes several option as to where the observation could have been made. Imaging / Laboratory et |
Code | Code refers to the test that is performed. This is the element bound to the LOIC coded elements. If suitable code is not exists in the value set, alternate code(s) may be provided |
Subject | Patient whose characteristics are described by the observation and into whose record the observation is documented |
Effective Date | For lab test, this is the date and tie this observation was made available to the provider |
Performer | Person who is responsible for asserting the observed value as 'True' |
ValueQuantity | An observation exists to have a vale, though it may not if it is in error, or it represents a group of observation |
Querying and retrieving Patient's Vitals
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Vitals
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/Vitals?fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's Vitals signs are returned. The following table describes the information returned.
Name | Description |
identifier | Unique Identifier for the observation instance. |
Status | Status of the result value or codes providing the status of the observation. The option includes, 'Final' , Preliminary' , 'Cancelled'. |
Category | Type of classification of the observation value. Clinical observations measures the body's basic functions such as 'Height' , 'Weight' , 'Heart Rate', 'Blood pressure'. For more details refer the value set http://hl7.org/fhir/Valueset/observation-category |
Code | Vital Signs result type are coded responses are from the CCDA Vital signs results. The codes shall be taken from CDA vital signs results. E.g. Weight is coded as "29463-7". |
Subject | Patient whose characteristics (Vital signs) are described by the observation and into whose record the observation is documented |
Encounter | Vitals Sign observation was obtained during a Healthcare event such as Encounter. |
EffectiveDateTime | Clinically relevant time/time-period for captured vitals signs. |
performer | The person responsible for documenting the observation (vital signs) to the patient charts |
valueQuantity | Vitals Signs value records with UCUM. Common UCUM units for recording the Vital Signs. The codes shall be taken from the UCUM units as defined in http://unitsofmeasure.org. e.g. include Height in (Kg) or (lbs.) |
valueQuantity.value | The value of the measured amount. The value includes an implicit precision in the presentation value |
valueQuantity.unit | A human-readable form of the units. |
Body Height | Recorded using the LOINC Code - 8302-2 using UOM cm or [in] |
Body Weight | Recorded using the LOINC Code - 29463-7 using UOM kg or lb. |
Body Temperature | Recorded using the LOINC Code - 8310-5 using UOM of Cel or [degF] |
Oxygen Saturation | Recorded using LOINC Code - 59408-5 using UOM of % Oxygen saturation in arterial blood by pulse oximetry |
Body mass Index | Recorded using LOINC Code 39156-5 using UOM kg/m2 |
Blood Pressure (Systolic and Diastolic) | Recorded using LOINC Code 8462-2 for Diastolic Blood pressure and LOINC Code 8480-6 for Systolic blood pressure using UOM mm[Hg] |
Respiratory Rate | Recorded using LOINC Code 9791-1 using UOM of (breaths)/min |
Querying and retrieving a patient's CCDA documents
The patient's PID is used to retrieve is passed as part of the URL. The logical ID is found as the result of a search.
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/DocumentReference
GET https://services.ezemrx.com /ezEMRx/ezFHIR/Patient/id/DocumentReference? fromDate=ge01-01-2018&toDate=le01-10-2018
Name | Description |
id | The logical ID of the patient. This is retrieved using the search function. |
fromDate | A string representing a from date to include in the search. See below for more information. |
toDate | A string representing a to date to include in the search. See below for more information. |
The patient's FHIR DocumentReference (CCDA) is returned.