Welcome

Patient Inbounding SSO

SSO Integration Protocol

Term Explanation

No.	Term	Description
1	SSO	Single sign-on (SSO) is a session and user authentication service that permits a user to use one set of login credentials (e.g. username and password) to access multiple applications.
2	Fed-SSO	Federation single sign-on (Fed-SSO), which allows users to login without passwords, is one of the many SSO solutions.
3	SAML2	Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML standard for exchanging authentication and authorization data between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is, an identity provider (IDP), and a SAML consumer, that is, a service provider (SP).
4	IDP	An Identity Provider (IDP), also known as Identity Assertion Provider, is responsible for providing identifiers for users looking to interact with a system, asserting to such a system that such an identifier presented by a user is known to the provider, and possibly providing other information about the user that is known to the provider. In MDLIVE Fed-SSO Integration, Client’s Server is the IDP server.
5	SAML2 IDP	SAML2 IDP is an Identify Provider which can generate SAML2 assertions with information about the end user. Client MUST have a SAML2 IDP for MDLIVE Fed-SSO Integration.
6	SAML2 SP	SAML2 SP is a Service Provider which can consume and process SAML2 assertions from authorized SAML2 IDPs. In MDLIVE Fed-SSO Integration, MDLIVE Fed-SSO Service is the SAML2 SP.
7	IDP-initiated	In IDP-initiated SSO, the Federation process is initiated by the IDP sending an unsolicited SAML Response to the SP.

MDLIVE SSO Integration Protocol

No.	Integration	Protocol
1	Initiator	Client’s SAML2 IDP
2	Protocol	SAML 2.0
3	SAML Profile	Web Browser
4	SAML Binding	HTTPS Post

HTTPS Post Request Body Security Protocol

No.	Security Protocol	Supported
1	SAML2 Assertion Level Base64 Format Encoding	YES (Recommended)
2	SAML2 Assertion Level Encryption with SP Public Certificate	YES
3	SAML2 Assertion Attribute Level Encryption	NO
4	SAML2 Assertion Level Plain Text	NO

SSO Including Registration UX

SSO Seamless UX

SSO with Real Time Eligibility

No.	Attribute Name Format	Supported
1	urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified	YES
2	urn:oasis:names:tc:SAML:2.0:attrname-format:uri	YES
3	urn:oasis:names:tc:SAML:2.0:attrname-format:basic	YES

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Member Legal First Name case-insensitive
3	lastname	Required	Member Legal Last Name case-insensitive
4	gender	Required	Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	subscriberid	Required	Customer ID / Member ID / Subscriber ID The same ID which is sent in 270 request to verify the member real time eligibility. Maximum 20 characters case-insensitive

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Dependent Member Legal First Name case-insensitive
3	lastname	Required	Dependent Member Legal Last Name case-insensitive
4	gender	Required	Dependent Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Dependent Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	subscriberid	Required	Dependent Customer ID / Dependent Member ID / Dependent Subscriber ID The same ID which is sent in 270 request to verify the member real time eligibility. Maximum 20 characters case-insensitive
7	relationship	Required	Relationship Code !! This Attribute is CASE-SENSITIVE !! Attribute value ONLY accept: Spouse Child Other Adult
8	primaryfirstname	Required	Primary Member Legal First Name case-insensitive
9	primarylastname	Required	Primary Member Legal Last Name case-insensitive
10	primarygender	Required	Primary Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
11	primarybirthdate	Required	Primary Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
12	primarysubscriberid	Required	Primary Customer ID / Primary Member ID / Primary Subscriber ID The same ID which is sent in 270 request to verify the member real time eligibility. Maximum 20 characters case-insensitive

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Member Legal First Name case-insensitive
3	lastname	Required	Member Legal Last Name case-insensitive
4	gender	Required	Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	subscriberid	Required	Customer ID / Member ID / Subscriber ID The same ID which is sent in 270 request to verify the member real time eligibility. Maximum 20 characters case-insensitive
7	memberid	Optional	GUID / UUID from the client side. The member ID should not change in the life time of account on the client side. Maximum 36 characters case-insensitive
8	phone	Required	Member Phone Number Format: 10 digit phone number Example: 8004006354
9	email	Required	Member Email Format: MUST be a valid email address Example: test@mdlive.com case-insensitive
10	address1	Required	Member Address case-insensitive
11	city	Required	Member Address City case-insensitive
12	state	Required	!! This Attribute is CASE-SENSITIVE !! Member Address State Abbreviation Format: 2 Upper Case State Abbreviation Example: FL, NY, CA
13	zip	Required	Member Address Zip Code Format: 5 digit zip code Example: 33325

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Dependent Member Legal First Name case-insensitive
3	lastname	Required	Dependent Member Legal Last Name case-insensitive
4	gender	Required	Dependent Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Dependent Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	subscriberid	Required	Dependent Customer ID / Dependent Member ID / Dependent Subscriber ID The same ID which is sent in 270 request to verify the member real time eligibility. Maximum 20 characters case-insensitive
7	memberid	Optional	GUID / UUID from the client side. The member ID should not change in the life time of account on the client side. Maximum 36 characters case-insensitive
8	phone	Required	Dependent Member Phone Number Format: 10 digit phone number Example: 8004006354
9	email	Required	Dependent Member Email Format: MUST be a valid email address Example: test@mdlive.com case-insensitive
10	address1	Required	Dependent Member Address 01 case-insensitive
11	address2	Optional	Dependent Member Address 02 case-insensitive
12	city	Required	Dependent Member Address City case-insensitive
13	state	Required	!! This Attribute is CASE-SENSITIVE !! Dependent Member Address State Abbreviation Format: 2 Upper Case State Abbreviation Example: FL, NY, CA
14	zip	Required	Dependent Member Address Zip Code Format: 5 digit zip code Example: 33325
15	relationship	Required	Relationship Code !! This Attribute is CASE-SENSITIVE !! Attribute value ONLY accept: Spouse Child Other Adult
16	primaryfirstname	Required	Primary Member Legal First Name case-insensitive
17	primarylastname	Required	Primary Member Legal Last Name case-insensitive
18	primarygender	Required	Primary Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
19	primarybirthdate	Required	Primary Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
20	primarysubscriberid	Required	Primary Customer ID / Primary Member ID / Primary Subscriber ID The same ID which is sent in 270 request to verify the member real time eligibility. Maximum 20 characters case-insensitive

SSO with Preloaded Eligibility

No.	Attribute Name Format	Supported
1	urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified	YES
2	urn:oasis:names:tc:SAML:2.0:attrname-format:uri	YES
3	urn:oasis:names:tc:SAML:2.0:attrname-format:basic	YES

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Member Legal First Name case-insensitive
3	lastname	Required	Member Legal Last Name case-insensitive
4	gender	Required	Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	memberid	Optional	REF02 field in 834 file member_id field in CSV file external_id field in MDLIVE Eligibility Server (API) Maximum 36 characters case-insensitive

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Member Legal First Name case-insensitive
3	lastname	Required	Member Legal Last Name case-insensitive
4	gender	Required	Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	memberid	Optional	REF02 field in 834 file member_id field in CSV file external_id field in MDLIVE Eligibility Server (API) Maximum 36 characters case-insensitive
7	phone	Required	Member Phone Number Format: 10 digit phone number Example: 8004006354
8	email	Required	Member Email Format: MUST be a valid email address Example: test@mdlive.com case-insensitive
9	address1	Required	Member Address case-insensitive
10	city	Required	Member Address City case-insensitive
11	state	Required	!! This Attribute is CASE-SENSITIVE !! Member Address State Abbreviation Format: 2 Upper Case State Abbreviation Example: FL, NY, CA
12	zip	Required	Member Address Zip Code Format: 5 digit zip code Example: 33325

SSO with No Eligibility (DTC)

No.	Attribute Name Format	Supported
1	urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified	YES
2	urn:oasis:names:tc:SAML:2.0:attrname-format:uri	YES
3	urn:oasis:names:tc:SAML:2.0:attrname-format:basic	YES

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Member Legal First Name case-insensitive
3	lastname	Required	Member Legal Last Name case-insensitive
4	gender	Required	Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	memberid	Required	GUID / UUID from the client side. The member ID should not change in the life time of account on the client side. Maximum 36 characters case-insensitive

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Member Legal First Name case-insensitive
3	lastname	Required	Member Legal Last Name case-insensitive
4	gender	Required	Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	memberid	Required	GUID / UUID from the client side. The member ID should not change in the life time of account on the client side. Maximum 36 characters case-insensitive
7	phone	Required	Member Phone Number Format: 10 digit phone number Example: 8004006354
8	email	Required	Member Email Format: MUST be a valid email address Example: test@mdlive.com case-insensitive
9	address1	Required	Member Address 01 case-insensitive
10	address2	Optional	Member Address 02 case-insensitive
11	city	Required	Member Address City case-insensitive
12	state	Required	!! This Attribute is CASE-SENSITIVE !! Member Address State Abbreviation Format: 2 Upper Case State Abbreviation Example: FL, NY, CA
13	zip	Required	Member Address Zip Code Format: 5 digit zip code Example: 33325

SSO for DTC EAP Member

No.	Attribute Name Format	Supported
1	urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified	YES
2	urn:oasis:names:tc:SAML:2.0:attrname-format:uri	YES
3	urn:oasis:names:tc:SAML:2.0:attrname-format:basic	YES

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue the ou value to the client. case-insensitive
2	firstname	Required	Member Legal First Name case-insensitive
3	lastname	Required	Member Legal Last Name case-insensitive
4	gender	Required	Member Gender M or Male for Male F or Female for Female U or N or Non-binary for Non-binary Gender case-insensitive
5	birthdate	Required	Member Birthdate Format: DD-MM-YYYY Example: 30-08-1990
6	memberid	Required	Member GUID (Globally Unique Identifier) Maximum 36 characters case-insensitive Note: Client needs to send MDLIVE the Member Globally Unique Identifier to identify members in the case if members have identical demographics information (first name, last name, gender, and birthdate). For example, Cigna can send Un-encrypted Cigna-Enterprise-ID as the memberid.
7	eapcode	Required	EAP Authorization Code Example: 010622221989
8	eapstartdate	Required	Service Start Date for the EAP Authorization Code Format: DD-MM-YYYY Example: 30-08-2023 Note: EAP Start Date needs to be the current date or a future date under Eastern Standard Time.
9	eapenddate	Required	Service End Date for the EAP Authorization Code Format: DD-MM-YYYY Example: 30-08-2024 Note: EAP End Date needs to be a date later than EAP Start Date EAP End Date needs to be within 1 year between EAP Start Date under Eastern Standard Time.
10	eapapprovedvisits	Required	Total Number of Approved EAP Visits Example: 5
11	email	Optional	Member Email case-insensitive Format: MUST be a valid email address Example: test@mdlive.com
12	phone	Optional	Member Phone Number Format: 10 digit phone number Example: 8004006354
13	address1	Optional	Member Address 01 case-insensitive
14	address2	Optional	Member Address 02 case-insensitive
15	city	Optional	Member Address City case-insensitive
16	state	Optional	!! This Attribute is CASE-SENSITIVE !! Member Address State Abbreviation Format: 2 Upper Case State Abbreviation Example 1: FL Example 2: CA Example 3: NY
17	zip	Optional	Member Address Zip Code Format: 5 digit zip code Example: 33325

SSO Configuration for Patient

No.	Environment	Item	Value	Description
1.1	Staging	SP Entity ID	https://stage-sso.mdlivetechnology.com/shibboleth	Audience in Audience Restriction This value is Case Sensitive in the SAML2 assertion. This is the name (EntityID) of MDLIVE Test SP Server which should be configured in the SAML2 assertion as the Audience. You will see a 404 Not Found Error Page if you try to access this URL directly from a web browser, which is expected.
1.2	Staging	Destination	https://stage-sso.mdlivetechnology.com/Shibboleth.sso/SAML2/POST	Assertion Consumer Service This value is Case Sensitive in the SAML2 assertion. You will see a Page Not Found MDLIVE Error Page if you try to access this URL directly from a web browser, which is expected.
1.3	Staging	Relay State	https://stage-sso.mdlivetechnology.com/sso/goto.jsp	NOT URL-encoded You will see a Page Not Found MDLIVE Error Page if you try to access this URL directly from a web browser, which is expected.
1.4	Staging	SP Metadata	MDLIVE SSO Staging SP Metadata (2026/03/05)	The SP metadata installation in the IDP server is not required for the SSO integration.
1.5	Staging	Certificate	MDLIVE SSO Staging Certificate (2026/03/05)	The Digital Certificate is being used to encrypt SAML2 assertion by clients IDP servers.
2.1	Production	SP Entity ID	https://sso.mdlive.com/shibboleth	Audience in Audience Restriction This value is Case Sensitive in the SAML2 assertion. This is the name (EntityID) of MDLIVE Production SP Server which should be configured in the SAML2 assertion as the Audience. You will see a 404 Not Found Error Page if you try to access this URL directly from a web browser, which is expected.
2.2	Production	Destination	https://sso.mdlive.com/Shibboleth.sso/SAML2/POST	Assertion Consumer Service This value is Case Sensitive in the SAML2 assertion. You will see a opensaml::BindingException Error Page if you try to access this URL directly from a web browser, which is expected.
2.3	Production	Relay State	https://sso.mdlive.com/sso/goto.jsp	NOT URL-encoded You will see a Unknown or Unusable Identity Provider Error Page if you try to access this URL directly from a web browser, which is expected.
2.4	Production	SP Metadata	MDLIVE SSO Production SP Metadata (2026/03/04)	The SP metadata installation in the IDP server is not required for the SSO integration.
2.5	Production	Certificate	MDLIVE SSO Production Certificate (2026/03/04)	The Digital Certificate is being used to encrypt SAML2 assertion by clients IDP servers.

SSO Sign Out

No.	Environment	Iframe URL
1	Staging	<iframe src="https://stage-members.mdlivetechnology.com/login/logout" style="display:none" id="mdlive-logout" />
2	Production	<iframe src="https://members.mdlive.com/login/logout" style="display:none" id="mdlive-logout" />

SSO Certificate Update

No.	Item
1	Preferred certificate update time in EST
2	Updated production certificate
3	IDP entityID
4	One live member account to test SSO after certificate update

SSO Error Handling

No.	Scenario
1	A required Assertion Attribute is missing or empty.
2	When provisioning a new patient profile, eligibility information cannot be verified based on the values provided in the Assertion attributes. This could mean the SAML Assertion data was missing required fields, or the eligibility information is not up to date or that there is a mismatch between the SAML Assertion data and the eligibility data.

Patient Outbounding SSO

Patient Outbounding SSO Workflow

Step 01: MDLIVE sends the User SSO OAuth Token to the client via a HTTP Redirection

The client needs to provide MDLIVE one URL for test environment and one URL for production environment to receive the User SSO OAuth Token.

The URL should looks like: https://CLIENT_WEB_BASE_URL/mdlive/index.html#/sso/mdlive/token/USER_SSO_OAUTH_TOKEN

Please save the User SSO OAuth Token and it will be required in Step 03.

Step 02: Client uses api_key and password to get API Authentication Token

HTTP Request

No.	Item	Description
1	HTTP URL	{MDLIVE_BASE_URL}/auth/auth_token
2	HTTP Method	POST

Header Parameter

Parameter	Default
Content-type	application/json

Request Body

Attribute	Required	Description
auth	true	parent attribute of api_key and password
↳ api_key	true	Unique api_key assigned to your team by MDLIVE
↳ password	true	Unique password assigned to your team by MDLIVE

Response Body

Attribute	Description
jwt	API Authentication Token This token will be expired in 24 hours.

Examples

No.	Item	Examples
1	Request Example	curl -X POST \   https://stage-rest-api.mdlivetechnology.com/auth/auth_token \   -H 'Content-Type: application/json' \   -d '{     "auth": {         "api_key": "mdlivedemoapikey",         "password": "mdlivedemoapipswd"     } }'
2	Response Example	{     "jwt":"Please save the API Authentication Token and it will be required in Step 03" }

Step 03: Client uses the User SSO OAuth Token (from Step 01) and the API Authentication Token (from Step 02) to obtain member information

HTTP Request

No.	Item	Description
1	HTTP URL	{MDLIVE_BASE_URL}/api/v1/sso_tokens/USER_OAUTH_SSO_TOKEN
2	HTTP Method	GET

Header Parameter

Parameter	Default
Authorization	API Authentication Token (from Step 02)

Response Body

Attribute	Description
patient	Patient Information
↳ id	Patient MDLIVE User ID Please save this Patient MDLIVE User ID and link with your GUID/UUID for reporting purpose.
↳ first_name	Patient First Name
↳ last_name	Patient Last Name
↳ gender	Patient Gender
↳ birthdate	Patient Birthdate
↳ email	Patient Email
↳ phone	Patient Phone Number
↳ address1	Patient Address1
↳ city	Patient Address City
↳ state	Patient Address State
↳ zip	Patient Address Zipcode
↳ dermatology_price	Price for Dermatology Visit

Examples

No.	Item	Examples
1	Request Example	curl -X GET \   https://stage-rest-api.mdlive.com/api/v1/sso_tokens/N_k8zXDeVo0PjuFzApPWKQ== \   -H 'Authorization: Please Copy The API Authentication Token (unexpired) from Step 02 and Paste Here.' N_k8zXDeVo0PjuFzApPWKQ==, in this Request Example, is a demo member User SSO OAuth Token. Please replace this demo member User SSO OAuth Token with your own User SSO OAuth Token from Step 01.
2	Response Example	{     "patient":{         "id":542128387,         "first_name":"oauth",         "last_name":"sso",         "gender":"Male",,         "birthdate":"1980-08-08"         "email":"test@mdlive.com",         "phone":"8004006354",         "address1":"123 Test Road",         "city":"FORT LAUDERDALE",         "state":"FL",         "zip":"33325",         "dermatology_price":"$69.00"     } }

Step 04: Client uses the member information (from Step 03) to register the member or login the member into the client site.

The client can implement this step based on the client's business logic.

OneClickConnect

OCC Introduction

OCC Whitelisting IP/Ports

OCC Epic App Orchard

OCC Standalone

OCC Provider Features

No.	Functionality	Control Button	Function Explanation
1	Turn on/off camera		The camera is default as on. The provider can turn off the camera, and the patient will no longer see the patient.
2	Turn on/off microphone		The microphone is default as on. The provider can turn off the microphone, and the patient will no longer hear the patient.
3	Turn on/off video preview		The video preview (the provider can see what the patient is seeing via a small video window) is default as on. The provider can turn off the video preview. The patient still can see the provider with the provider's video preview off. The patient can see the provider until the provider turn off the camera.
4	Invite third participant		The provider can invite third participant (nurse, translator, etc) to join the video room. The providers need to share the link to the third participant. The third participant needs to join the video room with the link. The third participant will have the same feature as a patient. The provider can both see and hear patient and third participant. The patient can both see and hear provider and third participant. The third participant can both see and hear provider and patient.
5	Screen sharing		The screen sharing is default as off. The provider can share the screen with the patient. The provider can choose to share the Entire Screen, Application Window, or Browser Tab.
6	Connect interpreter		This feature is default as off. The feature will be enabled ONLY when the healthcare entity has interpreter service provided to their patients and request to enable this feature. The provider can connect to a interpreter by using this feature. After the provider chooses the language, the corresponding phone number will be dialed to connect the interpreter into the video room with the patient and provider.
7	Change Background		This feature is default as off. The feature will allow a provider to choose a preferred background image.
8	Exit/end visit		The provider can click the exit button to exit the video room. There will be 2 options for the provider to exit the video room. If the provider choose to Exit the video room, only the provider will be exiting the video room. The provider will be redirected to a page which instructs that it is safe to close the browser window. The patient and other participants will stay in the video room if the provider chooses exit with Exit option. If the provider choose to End the video consult, all the participants will be disconnected from the video session/room. All the participants (provider, patient, third participant) will be redirected to a page which instructs that it is safe to close the browser window. The patient and other participants will be disconnected from the video room if the provider chooses exit with End option.

OCC Patient Features

No.	Functionality	Control Button	Function Explanation
1	Turn on/off camera		The camera is default as on. The patient can turn off the camera, and the provider will no longer see the patient.
2	Turn on/off microphone		The microphone is default as on. The patient can turn off the microphone, and the provider will no longer hear the patient.
3	Turn on/off video preview		The video preview (the patient can see what the provider is seeing via a small video window) is default as on. The patient can turn off the video preview. The provider still can see the patient with the patient's video preview off. The provider can see the patient until the patient turn off the camera.
4	Patient waiting room		The patient will first see this waiting room until the provider joins the video appointment.
5	Exit video room		The patient can click the exit button to exit the video room. The patient needs to choose "Yes" to confirm the exit operation. The patient will be redirected to a page which instructs that it is safe to close the browser window.

Eligibility API

No.	Environment	Item	Value	Description
1.1	Staging (UAT)	Base URL	https://stage-members.mdlivetechnology.com/services/
1.2	Production	Base URL	https://members.mdlive.com/services/
2.1	Required for All	HTTP Request Header: Content-Type	application/json
2.2	Required for All	HTTP Request Header: Authorization	application/json	Each API user is assigned an API Key and Secret pair that will grant access to the API. MDLIVE uses HTTP BASIC Authentication where the key and secret are used as the username and password respectively. This needs to be sent as part of the Header in the API request. Example: Authorization: Basic <Base64 encoding of "key:secret">
2.3	Required for All	HTTP Request Header: RemoteUserId	application/json	Use this header to specify which user triggered this API call. This is required for auditing purposes and requests without this header would be declined. This can be your organization name.

No.	Item	Description
1	Storing MDLIVE Member IDs	Client is responsible for storing MDLIVE Member ID (or unique identifier) in their system. When an API call to add a member is passed to MDLIVE, MDLIVE will respond back with a MDLIVE Member ID that is associated to that member / person record. This MDLIVE Member ID must be used when making any modifications or deleting the member.
2	MDLIVE does not deny service	MDLIVE will not deny service to a member that calls for a consult. If the member is not in our system and provides the group / employer name, our call center will add them into our system so that they can proceed with their consult. At the time the member is added into our system, MDLIVE will generate a new MDLIVE Member ID.

Eligibility API - Functionality

No.	Item	Value
1	Functionality	Add New Member
2	Description	Use this method to add eligibility data for a new patient.
3	Path	/members/
4	Request Method	POST
5	Required Parameters	1. first_name (first name of patient) 2. last_name (last name of patient) 3. gender (Male or Female) 4. birthdate (in DD-MM-YYYY format) 5. phone (primary phone number of patient) 6. email (primary email id of patient) 7. address1 (address line 1) 8. city (city of the patient) 9. state (2 letter state code) 10. zip (zip code)
6	Conditional Parameters	1. external_id       This is a unique identifier for the member in your system.       The external_id can be something like SSN or member id or anything else which can be used to uniquely identify the member in your system/database.       Required for adding primary members, and is desired but can be skipped when adding dependents. 2. plan_identifier       An identifier indicating which plan should be assigned to the patient.       Required if there are multiple plans associated with the API user. 3. parent_id       Required for adding dependents.       Should contain ID of the primary patient.
7	Optional Parameters	1. address2 (Address line 2) 2. emergency_contact (Emergency contact number) 3. work_phone (Work or office phone if available) 4. cell (Mobile number if available) 5. reporting1       Any attribute that you want to be able to store and run reports on later.       This is not used within MDLIVE system and is purely for storing additional information if required for the API consumer. 6. reporting2 (Same as reporting1) 7. reporting3 (Same as reporting1) 8. reporting4 (Same as reporting1) 9. subscriber_id (Subscriber ID of the member, including any suffix/prefix.) 10. insurance_group_number (Group number/ID of the insurance plan the member is on.)
8	Response Status	Response status will be 201 if the request is successful.       JSON representation of member data containing the "id" field assigned by MDLIVE system.       This id should be stored by the client applications as it is required for other API methods. See Errors section for details on errors.
9	Request Example    - Add a Primary	Request: external_id is required for adding a primary member.    POST https://members.MDLIVE.com/services/members             {                   "member": {                         "external_id": "guid-123-abc-xyz",                         "first_name": "John",                         "last_name": "Smith",                         "gender": "Male",                         "birthdate": "25-06-1989",                         "phone": "8004006354",                         "email": "test@mdlive.com",                         "address1": "123 Test Road",                         "city": "Sunrise",                         "state": "FL",                         "zip": "33325"                   }             }
10	Response Example    - Add a Primary	Response:    The id (MDLIVE ID) is assigned by MDLIVE system when the eligibility data of this patient was created.    This id (MDLIVE ID) should be stored by the client applications as it is required for other API methods.    This id (MDLIVE ID) will be used to add dependents under this primary account.    {          "member": {                   "id": 1000001,                   "status": "active",                   "first_name": "John",                   "last_name": "Smith",                   "gender": "Male",                   "birthdate": "25-06-89",                   "phone": "8004006354",                   "email": "test@mdlive.com",                   "address1": "123 Test Road",                   "address2": null,                   "city": "Sunrise",                   "state": "FL",                   "zip": "33325",                   "country": "US",                   "emergency_contact_number": null,                   "reporting1": null,                   "reporting2": null,                   "reporting3": null,                   "reporting4": null,                   "parent_id": null          }    }
11	Request Example    - Add a Dependent	Request: parent_id is required for adding a dependent member.    POST https://members.MDLIVE.com/services/members             {                   "member": {                         "parent_id": "1000001",                         "first_name": "Baby",                         "last_name": "Smith",                         "gender": "Female",                         "birthdate": "15-10-2010",                         "phone": "8004006354",                         "email": "test@mdlive.com",                         "address1": "123 Test Road",                         "city": "Sunrise",                         "state": "FL",                         "zip": "33325"                   }             }

No.	Item	Value
1	Functionality	Read Existing Member Information
2	Description	Use this method to get eligibility data for an existing patient as stored on MDLIVE system.
3	Path	/members/id/
4	Request Method	GET
5	Required Parameters	id: The MDLIVE ID assigned by MDLIVE system when the eligibility data of this patient was created. This should be set in the path.
6	Response Status	Response status will be 200 if the request is successful.       JSON representation of member data containing the "status" field to show the member's current activation status. Same as Create Member method. See Errors section for details on errors.
7	Example    - Read Member Information	Request:    GET https://members.mdlive.com/services/members/2 Response:    Same as Create Member method

No.	Item	Value
1	Functionality	Update Existing Member
2	Description	Use this method to modify eligibility data for an existing patient.
3	Path	/members/id/
4	Request Method	PUT
5	Required Parameters	id: The MDLIVE ID assigned by MDLIVE system when the eligibility data of this patient was created. This should be set in the path.
6	Optional Parameters	All required or optional parameters from the "Create Member" API Method
7	Response Status	Response status will be 204 if the request is successful. Same as Create Member method. See Errors section for details on errors.
8	Example    - Update Member	Request:    PUT https://members.mdlive.com/services/members/2             {                   "member": {                         "last_name": "Smith"                   }             } Response:    Same as Create Member method

No.	Item	Value
1	Functionality	Deactivate Existing Member
2	Description	Use this method to deactivated an existing patient.
3	Path	/members/id/
4	Request Method	DELETE
5	Required Parameters	id: The MDLIVE ID assigned by MDLIVE system when the eligibility data of this patient was created. This should be set in the path.
6	Response Status	Response status will be 204 if the request is successful. No content is returned from the server just the response status. See Errors section for details on errors.
7	Example    - Deactivate Member	Request:    DELETE https://members.mdlive.com/services/members/2 Response:    No Content

No.	Item	Value
1	Functionality	Reactivate Existing Member
2	Description	Use this method to re-activate a deactivated patient.
3	Path	/members/id/reactivate
4	Request Method	PUT
5	Required Parameters	id: The MDLIVE ID assigned by MDLIVE system when the eligibility data of this patient was created. This should be set in the path.
6	Response Status	Response status will be 204 if the request is successful. No content is returned from the server just the response status. See Errors section for details on errors.
7	Example    - Reactivate Member	Request:    PUT https://members.mdlive.com/services/members/2/reactivate Response:    No Content

Eligibility API - Testing

No.	Test Case	Description
1	Add a primary member	MDLIVE will check the system and confirm the member is added. One user per plan if the client has more than one plan.
2	Update the primary member	MDLIVE will check the system and confirm the member is updated.
3	De-activate the primary member	MDLIVE will check the system and confirm the member is de-activated.
4	Re-activate the primary member	MDLIVE will check the system and confirm the member is re-activated.
5	Read primary member info	MDLIVE will change the information on this member account in MDLIVE system.
6	Read primary member info again	Client should see the changes MDLIVE made in Step 5.
7	Add a dependent member	MDLIVE will check the system and confirm the member is added. This step will only be required if the client allows dependent.
8	Update the dependent member	MDLIVE will check the system and confirm the member is updated. This step will only be required if the client allows dependent.
9	De-activate dependent member	MDLIVE will check the system and confirm the member is de-activated. This step will only be required if the client allows dependent.
10	Re-activate dependent member	MDLIVE will check the system and confirm the member is re-activated. This step will only be required if the client allows dependent.
11	Read dependent member info	MDLIVE will change the information on this member account in MDLIVE system. This step will only be required if the client allows dependent.
12	Read dependent member info again	Client should see the changes MDLIVE made in Step 11. This step will only be required if the client allows dependent.

Eligibility API - Error

No.	Error Code	Description
1	400	[400 Bad Request] The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. This indicates that the required headers were missing or the request was not formed correctly.
2	401	[401 Unauthorized] This indicates that the Authentication header was missing or incorrect.
3	403	[403 Forbidden] The server understood the request, but is refusing to fulfill it. This indicates that you do not have permissions to access the requested resource/action.
4	404	[404 Not Found] The server has not found anything matching the Request-URI. This indicates that the requested resource was not found.
5	422	[422 Unprocessable Entity] This indicates that the data sent in API request is invalid or malformed. This will additionally return error description in following format: {error_field1: [array of error messages related to this attribute/parameter], error_field2: [array of error messages], … and so on} Any error message not pertaining to a specific parameter or attribute will be returned under the key "base". Example: {"first_name": ["must be present", "must not contain any numbers"], "birthdate": ["must be a past date"], "base": ["This patient was already saved earlier in our database"}
6	500	[500 Internal Server Error] The server encountered an unexpected condition which prevented it from fulfilling the request. This indicates something failed during processing your request and is not likely related to the data in the API request.

EHR Integration

The Continuity of Care Document (CCD) is a joint effort of HL7 International and ASTM.

CCD fosters interoperability of clinical data by allowing physicians to send electronic medical information to other providers without loss of meaning and enabling improvement of patient care.

CCD is an implementation guide for sharing Continuity of Care Record (CCR) patient summary data using the HL7 Version 3 Clinical Document Architecture (CDA), Release 2.

CCD establishes a rich set of templates representing the typical sections of a summary record, and expresses these templates as constraints on CDA.

These same templates for vital signs, family history, plan of care, and so on, can then be reused in other CDA document types, establishing interoperability across a wide range of clinical use cases.

The CCD is meant to be used by:

• Healthcare Providers
  
• Healthcare IT Vendors
  
• Electronic Health Record (EHR) and Personal Health Record (PHR) Systems
  

Benefits of the CCD include:

• Allows physicians to send electronic medical information to other providers without loss of meaning.
  
• Provides a "snapshot in time," constraining a summary of the pertinent clinical, demographic, and administrative data for a specific patient.
  
• Supports the ability to represent professional society recommendations, national clinical practice guidelines, standardized data sets, etc.
  

The CCD is intended as an alternate implementation to the one specified in ASTM ADJE2369 for those institutions or organizations committed to implementation of the HL7 Clinical Document Architecture. It represents a complete implementation of CCR, combining the best of HL7 technologies with the richness of CCRs clinical data representation, and does not disrupt the existing data flows in payer, provider or pharmacy organizations. The CCD is an XML-based standard and was recognized in 2008 by the US Secretary of Health and Human Services for this use. It has been named in US Regulations for exchange of clinical information.

The CCDA is based on components of two standard formats that were previously required for certified EHRs: the CCR and the CCD. This format was chosen as the standard for communicating the summary of care since it can accommodate all data elements that providers give their patients after office visits. HL7 created a single implementation guide for the Consolidated CDA, which was released in December 2011 in an effort to reduce ambiguity and eliminate conflicts in documentation. The Consolidated CDA solution encompasses a library of reusable CDA templates, setting the stage for streamlined development and quicker implementation.

EHR Integration Configuration

No.	Environment	Item	Detail
1	Staging && Production	OID	1.3.6.1.4.1.44503.5.1
2	Staging	Certificate	Download MDLIVE EHR Staging Certificate (2026/03/05)
3	Staging	Certificate Chain	Download MDLIVE EHR Staging Certificate Chain (2026/03/05)
4	Production	Certificate	Download MDLIVE EHR Production Certificate (2026/03/04)
5	Production	Certificate Chain	Download MDLIVE EHR Production Certificate Chain (2026/03/04)

EHR CCDA Push Transaction

Mobile - White Label

White Label App Assets

No.	Item	Required	Notes	Details
1	Installed App Icon Image	Required	This will be the Installed App Icon Image in both iOS and Android devices after the apps are installed. Size: 1024*1024. NO transparent background image. Example images with two different Installed App Icons are provided for reference =>
2	App Display Name	Required	This App Display Name will appear under the installed app icon within 12 characters - spaces count 1 character Examples of two different App Display Names are provided for reference =>
3	App Referring Name	Required	This App Referring Name will be used in the app, which will replace MDLIVE. within 12 characters - spaces count 1 character Examples of two different App Referring Names are provided for reference =>
4	Welcome Page Verbiage	Optional	The images on these (3) welcome pages cannot be changed in the white label apps. The welcome page verbiage including the title under each welcome page image can be customized upon client's request.
5	App Theme Color	Required	This is the App Theme Color of the white label app for both iOS and Android The Color Hex Value is required. Examples of two different App Theme Colors are provided for reference =>
6	App Resource Logo	Required	Size: 432*82 transparent background .png format Examples of two different App Resource Logos are provided for reference =>
7	DTC (Direct-to-Consumer) Registration Setting	Required	Please pick one of the following setting: 1. Client's DTC Benefit 2. MDLIVE's DTC Benefit	This setting is used when a first time user downloads and uses the white label app. If the user's current benefit is not covered by the white label app client (Health Entity or Employer), the user will be registered under a DTC benefit group to allow MDLIVE service access.

White Label App Launch

No.	Access	Requirement	Example
1	Google Play Store: Admin Access	required
2	App Store Connect: Admin Access	required

No.	Item	Format
1	App Name in Store	Any existing app name cannot be used. App Name must be less than 30 characters.
2	App Screenshots Background Color	Any client company branding Color Hex Value, like #8A1E41.
3	App Screenshots Pharmacy ZIP code	Any U.S. ZIP code, like 33027.

Platform	Usage
iOS
Android

White Label App FAQ

Q&A	Information
Q1	Does MDLIVE Support white label app for Windows OS or any other mobile OS?
A1	No, MDLIVE white label app ONLY support iOS and Android platforms.
Q2	Can MDLIVE release the white label app under MDLIVE developer account instead of my team's account?
A2	No, the client has to release the apps under their own Developer account.
Q3	Will there be user experience differences in the white label app between iOS and Android?
A3	Yes, MDLIVE has different road maps and release schedules for iOS and Android. Some new features will not be available at the same time between iOS app and Android app.
Q4	What is the upgrade plan for white label apps?
A4	MDLIVE will upgrade each white label app annually in Q4 each year.
Q5	Will MDLIVE upgrade white label apps outside of the annual upgrade window?
A5	MDLIVE will release hot-fix release for fixing production issues. If there is a new feature ready in MDLIVE white label app and the client wants the feature before the annual upgrade time window. MDLIVE can release a build based on client's request and MDLIVE product team approval.

Mobile - SDK

SDK - Intro

SDK - iOS Release

Release	Date	Features
MDLIVE iOS SDK 4.0.2	09/25/2024	Added support for Xcode 16.
MDLIVE iOS SDK 4.0.1	09/05/2024	Added support for Xcode 15.4.
MDLIVE iOS SDK 4.0.0	08/16/2024	New features: - Redesigned dashboard - E-Treatment
MDLIVE iOS SDK 3.3.5	05/30/2024	Added support for the updated Non-Production environment.
MDLIVE iOS SDK 3.3.4	05/13/2024	Minor fix for Apple Privacy Manifest File.
MDLIVE iOS SDK 3.3.3	04/22/2024	Added support for Apple Privacy Manifest.
MDLIVE iOS SDK 3.3.2	03/28/2024	Added support for Swift 5.9.2 and Xcode 15.
MDLIVE iOS SDK 3.3.1	01/01/2024	Removed the nested Validic framework.
MDLIVE iOS SDK 3.3.0	12/01/2023	Updated mobile Certificate Pinning. New expiration date: 12/05/2030.
MDLIVE iOS SDK 3.1.1	03/01/2023	Updated mobile Certificate Pinning. New expiration date: 01/17/2024.
MDLIVE iOS SDK 2.1.0	04/01/2022	New features: - Behavior appointment request - Annual wellness visit - Lab scheduling - Dashboard redesign

SDK - Android Release

Release Version	SDK Reference ID Links	Release Date	Release Note
MDLIVE Android SDK 3.3.0	MDL_artifact_version = "5.3.16"	12/01/2023	Updated mobile Certificate Pinning. New expiration date: 12/05/2030.
MDLIVE Android SDK 3.1.0	MDL_artifact_version = "5.3.15"	03/01/2023	Updated mobile Certificate Pinning. New expiration date: 01/17/2024.
MDLIVE Android SDK 2.1.1	MDL_artifact_version = "5.3.12"	07/01/2022	Updated SSL Error Handler to meet the latest Google Security requirements.
MDLIVE Android SDK 2.1.0	MDL_artifact_version = "5.3.9"	04/01/2022	New features: - Behavior appointment request - Annual wellness visit - Lab scheduling - Dashboard redesign

SDK - Entry Point API

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Member Legal First Name case-insensitive
3	lastname	Required	Member Legal Last Name case-insensitive
4	gender	Required	Member Gender M for Male F for Female U for Non-binary Gender case-insensitive
5	birthdate	Required	Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	subscriberid	Required	Member Subscriber ID The same ID which is sent in 270 request to verify the member real time eligibility. Maximum 20 characters case-insensitive
7	relationship	Required	Relationship Code !! This Attribute is CASE-SENSITIVE !! Attribute value ONLY accept: Self
8	memberid	Conditional	GUID / UUID from the client side. Please refer to your own integration document if you have a customized design on the member ID value. Maximum 36 characters case-insensitive
9	phone	Required	Member Phone Number Format: 10 digit phone number Example: 8004006354 The following error will be returned for new users if phone number is not sent as requested: {  "sdk_sso_transfer": {   "completed": true,   "eligible": false,   "reason": "{:phone=>[\"can't be blank\", \"is invalid\"]}",   "token": "random-token-generated-by-the-server",   "subscriberid": abc1234567",   "memberid": "xyz12345"  } }
10	email	Required	Member Email Format: MUST be a valid email address Example: test@mdlive.com The following error will be returned for new users if email is not sent as requested: {  "sdk_sso_transfer": {   "completed": true,   "eligible": false,   "reason": "{:email=>[\"can't be blank\", \"is invalid\"]}",   "token": "random-token-generated-by-the-server",   "subscriberid": abc1234567",   "memberid": "xyz12345"  } } case-insensitive
11	address1	Required	Member Address case-insensitive
12	city	Required	Member Address City case-insensitive
13	state	Required	Member Address State Abbreviation !! This Attribute is CASE-SENSITIVE !! Format: 2 Upper Case State Abbreviation Example: FL, NY, CA
14	zip	Required	Member Address Zip Code Format: 5 digit zip code Example: 33325

No.	Name	Requirement	Description
1	ou	Required	Organization Unit MDLIVE will issue one “ou” value for each client landing page. case-insensitive
2	firstname	Required	Dependent Member Legal First Name case-insensitive
3	lastname	Required	Dependent Member Legal Last Name case-insensitive
4	gender	Required	Dependent Member Gender M for Male F for Female U for Non-binary Gender case-insensitive
5	birthdate	Required	Dependent Member Birthdate Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
6	subscriberid	Required	Dependent Member Subscriber ID The same ID which is sent in 270 request to verify the dependent member real time eligibility. Maximum 20 characters case-insensitive
7	relationship	Required	Relationship Code !! This Attribute is CASE-SENSITIVE !! Attribute value ONLY accept: Spouse Child Other Adult
8	memberid	Conditional	GUID / UUID from the client side. Please refer to your own integration document if you have a customized design on the member ID value. Maximum 36 characters case-insensitive
9	phone	Required	Member Phone Number Format: 10 digit phone number Example: 8004006354 The following error will be returned for new users if phone number is not sent as requested: {  "sdk_sso_transfer": {   "completed": true,   "eligible": false,   "reason": "{:phone=>[\"can't be blank\", \"is invalid\"]}",   "token": "random-token-generated-by-the-server",   "subscriberid": abc1234567",   "memberid": "xyz12345"  } } case-insensitive
10	email	Required	Dependent Member Email Format: MUST be a valid email address Example: test@mdlive.com The following error will be returned for new users if email is not sent as requested: {  "sdk_sso_transfer": {   "completed": true,   "eligible": false,   "reason": "{:email=>[\"can't be blank\", \"is invalid\"]}",   "token": "random-token-generated-by-the-server",   "subscriberid": abc1234567",   "memberid": "xyz12345"  } } case-insensitive
11	address1	Required	Dependent Member Address case-insensitive
12	city	Required	Dependent Member Address City case-insensitive
13	state	Required	Dependent Member Address State Abbreviation !! This Attribute is CASE-SENSITIVE !! Format: 2 Upper Case State Abbreviation Example: FL, NY, CA
14	zip	Required	Dependent Member Address Zip Code Format: 5 digit zip code Example: 33325 case-insensitive
15	primaryfirstname	Required	Primary Member Legal First Name case-insensitive
16	primarylastname	Required	Primary Member Legal Last Name case-insensitive
17	primarygender	Required	Primary Member Gender M for Male F for Female U for Non-binary Gender case-insensitive
18	primarybirthdate	Required	Primary Member Birthdate Android Format: java.util.Date iOS Format: DD-MM-YYYY Example: August 12, 1999 -> 12-08-1999 case-insensitive
19	primarysubscriberid	Required	Primary Member Subscriber ID The same ID which is sent in 270 request to verify the member real time eligibility. Maximum 20 characters case-insensitive

Mobile - Webview

System Requirement

Patients System Requirement

No.	Requirements
1	2.0 GHz CPU with dual-core processor minimum (Recommended: 2.8 GHz 6th Generation Intel® Core™ i5 Processor with 4 CPU Cores or better, or an equivalent AMD processor)
2	2 GB RAM minimum (Recommended: 4 GB or more)
3	A webcam with at least 2 megapixels
4	Microphone (most webcams have a microphone built-in)
5	High-speed Internet with 1MB download and 300kbps minimum upload speed

No.	Product	Operating System
1	MDLIVE Web Site	Apple MacOS 10.12+
2	MDLIVE Web Site	Microsoft Windows 10
3	MDLIVE Web Site	Microsoft Windows 8.1
4	MDLIVE Web Site	Microsoft Windows 7 SP1
5	iOS Mobile Application	Apple iOS 10+
6	iPad Application	Apple iPadOS 13+
7	Android Mobile Application	Android 7 (Nougat)+

No.	Device	Operating System	Browser
1.1.1	Desktop	Microsoft Windows	Google Chrome
1.1.2	Desktop	Microsoft Windows	Firefox
1.1.3	Desktop	Microsoft Windows	Microsoft Edge Chromium: Version 80+
1.2.1	Desktop	Apple MacOS	Google Chrome
1.2.2	Desktop	Apple MacOS	Firefox
1.2.3	Desktop	Apple MacOS	Safari: Version 12.1+
1.3.1	Desktop	Linux	Google Chrome
1.3.2	Desktop	Linux	Firefox
2.1.1	Mobile	iOS	iOS Safari: Version 12.1+
2.2.1	Mobile	Android	Google Chrome
3.1.1	Tablet	iPad	Safari: Version 12.1+

Providers System Requirement

No.	Requirements
1	2.0 GHz CPU with dual-core processor minimum (Recommended: 2.8 GHz 6th Generation Intel® Core™ i5 Processor with 4 CPU Cores or better, or an equivalent AMD processor)
2	2 GB RAM minimum (Recommended: 4 GB or more)
3	A webcam with at least 2 megapixels
4	Microphone (most webcams have a microphone built-in)
5	High-speed Internet with 10MB download and 2MB minimum upload speed

No.	Product	Operating System
1	MDLIVE Web Site	Apple MacOS 10.12+
2	MDLIVE Web Site	Microsoft Windows 10
3	iOS Mobile Application	Apple iOS 10+
4	Android Mobile Application	Android 7 (Nougat)+

No.	Device	Operating System	Browser
1.1.1	Desktop	Microsoft Windows	Google Chrome
1.2.1	Desktop	Apple MacOS	Google Chrome

System Notice

20250310 EHR Stage Update Notice

20250311 SSO Stage Update Notice

20250317 EHR Production Update Notice

20250318 SSO Production Update Notice