USE CASE NO. 1 ADT NOTIFICATION SERVICE

USE CASE NO. 1 ADT NOTIFICATION SERVICE Use Case Category: Transitions of Care Optional Use Cases: 1. Active Care Relationship Service SM (ACRS) Submit Data Use Case Agreement 2. Health Provider Directory (HPD) Submit Data Use Case Agreement 1. GOAL. PatientPing seeks to assist Customer in leveraging existing or establishing new capabilities to share transitions of care information by sending and/or receiving Hospital Admission, Discharge and Transfer (ADT) events to those organizations that desire to be notified of such events. 2. PURPOSE. The purpose of this Use Case is to define PatientPing and Customer s roles and responsibilities for Customer to leverage PatientPing routing of ADT messages. 3. USE CASE EXAMPLE. Example: A patient is admitted to a hospital. The hospital sends an ADT Admit message to PatientPing. PatientPing checks the Active Care Relationship Service SM (ACRS) which contains information on what providers are associated with this patient. PatientPing checks the Health Provider Directory (HPD) to obtain the delivery preference for each of those providers (i.e. a secure Direct email, an ADT message via HL7, etc). PatientPing notifies the providers, based on their delivery preferences, that the patient has been admitted to the hospital. Other scenario s include when a patient is discharged from the hospital or is transferred to a different location (unit, bed) within the hospital or to another facility outside of the hospital. 4. DEFINITIONS. 4.1 Active Care Relationship means (a) for providers, a patient who has been seen by a provider within the past 24 months, or is considered part of Customer s active patient population they are responsible for managing; (b) for payers, an eligible member of a health insurance plan. 4.2 Active Care Relationship Service (ACRS) means the PatientPing Service that contains information on those Health Professionals who have an Active Care Relationship with a patient. 4.3 Admit, Discharge and Transfer (ADT) means a type of HL7 message generated by healthcare systems based upon event triggers; patient is admitted to, discharged from or transferred within or from the Master Services Agreement Use Case No. 1; Page 1

hospital to another care setting or to the patient s home. The HL7 ADT messages contain patient demographic, visit, insurance and diagnosis information. 4.4 ADT Message means HL7 Admission, Discharge, and Transfer (ADT) message type used to transmit patient demographic and/or health care encounter information, generated from ADT Source information system(s). 4.5 ADT Source means a health care organization generating the ADT Message and sending it or otherwise making it available to Customer and/or their participants. 4.6 ADT Recipient means the organization that will receive an ADT Message for a specific purpose. 4.7 Care Relationship means an active relationship between a patient and a healthcare Provider, Care Manager, Payer or other Organization for the purpose of treatment, payment or operations. 4.8 Conforming Message means a message that is in a standard format per the associated ADT Notification Service Implementation Guide. 4.9 Digital Credentials means a digital certificate, including Server Certificates, issued to Customer by PatientPing, its designee or trusted anchor. The Digital Credentials will be presented electronically by Customer to prove identity and the right to access Message Content through the PatientPing Service. 4.10 Electronic Address means a string that identifies the transport protocol and end point address for communicating electronically with a recipient. A recipient may be a person, organization or other entity that has designated the electronic address as the point at which it will receive electronic messages. Examples of an electronic address are an email address (Direct via SMTP) or URL (SOAP / XDR). Communication with an electronic address may require a digital certificate. 4.11 Electronic Service Information (ESI) means all information reasonably necessary to define an electronic destination s ability to receive and consume a specific type of information (e.g. discharge summary, patient summary, laboratory report, query for patient/provider/healthcare data). The information should include the type of information (e.g. patient summary or query) the destination s Electronic Address (see definition above), the Messaging Framework supported (e.g. SMTP, HTTP/SOAP), Security information supported or required (e.g. digital certificate) and specific payload definitions (e.g. CCD C32 V2.5). In addition, this information may include labels that help identify the type of recipient (e.g. medical records department). 4.12 Health Level 7 (HL7) means an interface standard and specifications for clinical and administrative healthcare data developed by the American National Standards Institute (ANSI) organization. HL7 provides a method for disparate systems to communicate clinical and administrative information in a normalized format with acknowledgement of receipt. 4.13 Health Plan means an individual or group plan that provides, or pays the cost of, medical care (as defined in section 2791(a)(2) of the Public Health Service Act, 42 U.S.C. 300gg-91(a)(2)). 4.14 Health Professional means any person holding a clinical or non-clinical position within or associated with an organization that provides healthcare or healthcare related services. People who contribute to the gathering, recording, processing, analysis or communication of health information. Examples include but are not limited to Physicians, Physician Assistants, Nurse Practitioners, Nurses, Medical Assistants, Home Health Professionals, Administrative Assistants, Receptionists, Clerks, etc. 4.15 Health Provider Directory (HPD) ( the Directory ) means the statewide shared service established by MiHIN Shared Services that contains contact information on Health Professionals, Healthcare Master Services Agreement Use Case No. 1; Page 2

Organizations, Electronic Addresses and Electronic Service Information, as a resource for authorized users to obtain efficient, accurate and reliable contact information and securely exchange health information. 4.16 Information Source means any organization that provides information that is added to the Directory. 4.17 Message means a mechanism for exchanging Message Content, as defined below, between PatientPing and Customer, through the PatientPing Services, including query, retrieve, and publish-subscribe. 4.18 Message Content means information which is requested, received or sent PatientPing through the PatientPing Services, including PHI, de-identified data, pseudonymized data, metadata, digital certificates and data schema. For this Use Case Agreement, the Message Content refers to the content of the HL7 ADT messages. 4.19 Network Downtime means a party is unable to transmit and receive data from the Internet for any reason, including but not limited to the failure of network equipment or software, scheduled or unscheduled maintenance, general Internet outages, and events of force majeure. 4.20 Person Record means any record in the Directory that primarily relates to an individual person. 4.21 Notice means a message transmission that is not Message Content and which may include but not be limited to an acknowledgement of receipt or error response. 4.22 Transactional Basis means on a per transaction basis, the transmission of Message Content or a Notice within sixty (60) seconds of delivery or receipt of Message Content or Notice from a sending or receiving party. 5. MESSAGE CONTENT. 5.1 Primary Use. 5.1.1 PatientPing will provide a service to receive ADT messages from Customer and/or their participants, determine care relationships based upon the Active Care Relationship Service SM, and send the ADT messages to MiHIN and any organization that is a party to a Qualified Data Sharing Organization Agreement or similar agreement with MiHIN and/or their participants (collectively, MiHIN Participants ) based upon routing destination and delivery preferences. Types of healthcare organizations receiving ADT messages may include but are not limited to physicians, care managers and payers. 5.1.2 The ADT message data shall be used for Treatment, Payment and Operations (each as defined under HIPAA). 5.2 Additional Permissible Use. 5.2.1 The parties may make additional use of the Message Content, provided that such additional use is consistent with Applicable Laws and Standards, as defined in the Agreement. 5.2.2 This data may be used for Public Health Reporting. 5.2.3 This data may be used for resolution of patient matching in support of a statewide Master Person Identification service. Master Services Agreement Use Case No. 1; Page 3

5.2.4 This data may be used to notify eligible patients or guardians that an admission, discharge or transfer has occurred. 5.3 Additional Terms. 5.3.1 Customer may contribute ADT information consistent with the terms herein and as otherwise permitted by the Agreement, provided, however, that in no case shall Customer share data in a manner inconsistent with this Use Case, as applicable. To the extent there is an express conflict between the terms herein and the Agreement, the Agreement, as applicable, shall prevail. 5.4 Limitations on use. This data may not be used for purposes of competing with MiHIN Participants. This provision is not intended to restrict Customer from competing with other MiHIN Participants; provided, however, that Customer does not use the data received or sent under this Use Case Agreement for such competition. 6. FEES. Fees related to this Use Case Agreement will be handled by mutual agreement between PatientPing and the Customer and shall not be transaction based. 7. SERVICE LEVEL. The parties desire that the Message Content and Notice exchange between Customer and/or their participants and PatientPing meet the service levels set forth below: 7.1 Timeliness of Exchange. The parties desire that the Message Content and Notice exchange occur on a Transactional Basis. 7.2 Transmission Failure. Notwithstanding Sections 4.22 (Transactional Basis) and 7.1 (Timeliness of Exchange), if the parties experience a Network Downtime or system outage, the Message Content and Notices shall be queued to the extent possible during the Transmission Failure and retransmitted as soon as system operations have been restored. Retransmitted message rate shall not exceed 1500 messages per minute, and the sender shall wait 5 minutes in between retransmissions. Transactions that have not been successfully retransmitted within 12 hours of the time of the event shall be recorded as a transmission error, but should still be transmitted as soon as possible. 8. AUDITING. 8.1 Abilities to Audit. Each party shall monitor and audit all access to and use of its system related to this Use Case, for system administration, security, and other legitimate purposes consistent with each such party s standard operating procedures. 8.2 Audit Logs. 8.2.1 Customer. Customer shall, at a minimum, log the following information: (i) date and time Message Content was accessed and identity (e.g., unique identifier) of individual or system, as applicable, accessing the Message Content; (ii) date and time Message Content was transmitted through the PatientPing Services and identity of individual or system, as applicable, transmitting the Message Content; (iii) date and time a Notice was sent or received from or to PatientPing; (iv) the unique message identifier for the Message Content accessed, sent, or received; (v) the HL7 segment accessed; and (vi) any Notices, failures, or network events. Master Services Agreement Use Case No. 1; Page 4

8.2.2 PatientPing. With respect to its obligations as a business associate, if applicable, PatientPing shall, at a minimum, log the following information: (i) name of Customer and/or participant accessing the PatientPing Services; (ii) identity (e.g., unique identifier) of individual or system, if applicable, accessing the Message Content; (iii) the date and time the access occurred; (iv) the HL7 segments accessed (v) the source IP address of the Message Content request; (vi) the destination IP address of the Message Content request; and (vii) any Notices, failures, or network events. Except as provided in the foregoing, PatientPing shall not be obligated to maintain and shall not be responsible for, either maintaining records of the content of any Message exchange between the parties or inspecting the content of such Messages. 8.3 Production of Audit Logs. Upon a good faith written request by a party, the nonrequesting party shall produce the requested audit logs within five (5) days from the date of the request to the requesting party or a detailed written explanation of why the requested logs cannot be produced. 8.4 Retention of Audit Logs. The parties shall retain audit logs in accordance with any and all requirements set forth in Applicable Laws and Standards, including but not limited to the requirements under the Health Insurance Portability and Accountability Act of 1996, Public Law 104-191, and regulations at 45 CFR Part 160, Part 162, and Part 164, the Michigan Public Health Code, MCL 333.1101 et seq., the Agreement, and as otherwise necessary to comply with this Use Case. 9. RESPONSIBILITIES OF THE PARTIES. 9.1 Customer s Responsibilities as ADT Senders. 9.1.1 Customer shall transmit to PatientPing the Message Content and Notices on a Transactional Basis. 9.1.2 Customer shall, on a Transactional Basis, transmit any Notices received from PatientPing to the Customer participant that submitted the Message Content, as necessary (e.g., transmitting an acknowledgment of submission received from PatientPing). 9.1.3 Customer shall transmit the data using PatientPing approved format, content and secure transport methods. 9.1.4 If the ADT transactions from the Customer to PatientPing fail to transfer successfully in full, the Customer shall retransmit, or make provisions to have the files retransmitted. 9.1.5 Customer shall transmit data to PatientPing only from organizations that have agreed to participate in this Use Case Agreement. 9.1.6 Customer agrees that providers and payers who have an Active Care Relationship with this patient may receive the ADT messages. However, Customer shall have the ability to opt-out of sending ADT Notifications to specific ADT Recipient organizations. 9.1.7 Notice of unauthorized receipt. In the event Customer sends or receives Message Content for which Customer is not authorized to send or receive, Customer will immediately inform PatientPing, delete such Message Content, and require its Authorized Users to do so. 9.1.8 Customer shall work with PatientPing to schedule and Master Services Agreement Use Case No. 1; Page 5

coordinate any changes to the production systems or networks involved in ADT Message sending, filtering, translating, or forwarding activities so as to ensure the reliability and availability of the production environments. 9.2 Customer s Responsibilities as ADT Receivers. 9.2.1 Customer shall receive the Message Content and Notices from PatientPing on a Transactional Basis. 9.2.2 Customer shall submit to PatientPing, on a Transactional Basis, any Notices received from Customer participant that received the message content, as necessary (e.g., transmitting an acknowledgment of submission received from Customer). 9.2.3 Customer shall receive the data using one of the PatientPing approved secure transport methods, format and content. 9.2.4 Customer shall transmit data only to other participating organizations that have agreed to participate in this Use Case and the prerequisite Use Case Agreements, as appropriate. 9.2.5 Customer and its participants shall work with PatientPing to update and maintain the associated Directories per the Active Care Relationship Service SM Submit Data Use Case Agreement and the Health Provider Directory Submit Data Use Case Agreement. 9.2.6 Customer and its participants shall provide and maintain correct Electronic Addresses and Electronic Service Information (ESI) within PatientPing Directories and/or Services. 9.2.7 If the Health Provider Directory and Active Care Relationship Service SM file transfers from the Customer to PatientPing fail to transfer successfully in full, the Customer shall retransmit or make provisions to have the files retransmitted. 9.2.8 Notice of unauthorized receipt. In the event Customer sends or receives Message Content for which Customer is not authorized to send or receive, Customer will immediately inform PatientPing, delete such Message Content, and require its Authorized Users to do so. 9.2.9 Customer shall work with PatientPing to schedule and coordinate any changes to the production systems or networks involved in ADT Message forwarding or receiving activities so as to ensure the reliability and availability of the production environments. 9.3 PatientPing s Responsibilities. Basis. 9.3.1 PatientPing shall transmit all Message Content and Notices on a Transactional 9.3.2 PatientPing shall transmit the ADT Messages it receives to MiHIN Participants as defined in the Active Care Relationship Service SM (ACRS), which is populated by ADT Receiving Organizations. 9.3.3 PatientPing may send ADT Message Content containing a Health Plan designation within the ADT Message Content to a Health Plan Participating Organization. 9.3.4 PatientPing shall discard all Message Content that does not have attribution Master Services Agreement Use Case No. 1; Page 6

defined within the Active Care Relationship Service SM (as described in 9.3.2) or is not a match based on other message content (as described in 9.3.3). 9.3.5 PatientPing shall not transmit Message Content to any Health Plan(s) if the Message Content indicates SELF-PAY as defined in the ADT Implementation Guide (accessible from the MiHIN website). 9.3.6 PatientPing shall be responsible for protecting ADT Message Content. 9.3.7 PatientPing shall work with Customer to schedule and coordinate any changes to the production systems or networks involved in ADT Message sending, filtering, translating, forwarding or receiving activities so as to ensure the reliability and availability of the production environments. 9.3.8 PatientPing shall work with Customer and/or its participants who are ADT Receivers to receive and process updates to the associated Directories per the Active Care Relationship Service SM Submit Data Use Case Agreement and the Health Provider Directory Submit Data Use Case Agreement. 10. OTHER TERMS. 10.1 Data Format, Validation and Transmission Specifications. 10.1.1 The Message Content submitted into the PatientPing Services must meet the HL7 2.5.1 Specifications for the Statewide ADT Notification Service implementation guide (the Conforming Message ) set forth for this Use Case on the MiHIN web site and all Message Content submitted to PatientPing shall meet these specifications. 10.1.2 ADT Message Content submitted to the PatientPing Services that does not meet the Specifications identified in 10.1.1 will be responded to with an HL7 NAK (Not Acknowledged) message. 10.1.3 PatientPing shall validate all Conforming Messages. 10.1.4 Disclaimers. (a) Prior to transmitting Conforming Messages to PatientPing, Customer shall ensure that each Conforming Message is from a participant that has entered into the appropriate Business, Data Sharing and Use Case Agreements. (b) Customer shall bear sole responsibility for ensuring that the Confirming Message meets the data integrity, format, security, and timeliness standards as identified in the Agreements. Master Services Agreement Use Case No. 1; Page 7

USE CASE NO. 2 USE CASE FOR SUBMIT DATA TO ACTIVE CARE RELATIONSHIP SERVICE (ACRS) Use Case Category: Transitions of Care Use Case Prerequisites: None 1. GOAL. PatientPing seeks to establish accurate data attributing patients to Health Professionals who are authorized to provide care and Health Plans who are authorized to reimburse for care by Customer. The data enables PatientPing to provide a service identifying Customer and Health Professionals using information within multiple Use Cases such as those related to Transitions of Care and Coordination, including Statewide ADT Notification Service and Medication Reconciliation as examples. This also supports sharing data with other infrastructure Use cases such as those related to the Statewide Health Provider Directory (HPD). 2. PURPOSE. The purpose of this Use Case is to define Customer and PatientPing roles and responsibilities as they relate to supplying and maintaining the data in the Active Care Relationship Service ( Service ). 3. USE CASE DIAGRAM. 4. DEFINITIONS. 4.1 Active Care Relationship means a) for providers, a patient who has been seen by a provider within the past 24 months or b) for payers, an eligible member of a health insurance plan. 4.2 Active Care Relationship Service (ACRS) means the HIN Service that contains information on those Participating Organizations and Health Professionals who have an Active Care Relationship with a patient. 4.3 Admit Discharge Transfer (ADT) means a type of HL7 message generated by healthcare systems based upon event triggers; patient is admitted to, discharged from or transferred within or from the hospital to another care setting or to the patient s home. The HL7 ADT messages contain patient demographic, visit, insurance and diagnosis information. 4.4 ADT Message means HL7 Admission, Discharge, and Transfer (ADT) message type used to transmit patient demographic and/or health care encounter information, generated from ADT Source information system(s). 4.5 Care Relationship means an active relationship between a patient and a healthcare Provider, Care Manager, Payer or other Organization for the purpose of treatment, payment or operations. 4.6 Electronic Address means a string that identifies the transport protocol and end point address for communicating electronically with a recipient. A recipient may be a person, organization or other entity that has designated the electronic address as the point at which it will receive electronic messages. Examples of an electronic address are an email address (Direct via SMTP) or URL (SOAP / XDR). Communication with an electronic address may require a digital certificate. 4.7 Electronic Service Information (ESI) means all information reasonably necessary to define an electronic destination s ability to receive and consume a specific type of information (e.g. discharge Master Services Agreement Use Case No. 2; Page 1

summary, patient summary, laboratory report, query for patient/provider/healthcare data). The information should include the type of information (e.g. patient summary or query) the destination s Electronic Address (see definition above), the Messaging Framework supported (e.g. SMTP, HTTP/SOAP), Security information supported or required (e.g. digital certificate) and specific payload definitions (e.g. CCD C32 V2.5). In addition, this information may include labels that help identify the type of recipient (e.g. medical records department). 4.8 Health Professional means any person holding a clinical or non-clinical position within or associated with an organization that provides healthcare or healthcare related services. People who contribute to the gathering, recording, processing, analysis or communication of health information. Examples include but are not limited to Physicians, Physician Assistants, Nurse Practitioners, Nurses, Medical Assistants, Home Health Professionals, Administrative Assistants, Receptionists, Clerks, etc. 4.9 Information Source means any organization that provides information that is added to the Service. 4.10 Network Downtime means a party is unable to transmit and receive data from the Internet for any reason, including but not limited to the failure of network equipment or software, scheduled or unscheduled maintenance, general Internet outages, and events of force majeure. 5. MESSAGE CONTENT.Primary Use. Populate and maintain up-to-date Service information for the purpose of identifying Health Professionals authorized to provide care to patients. Customer will provide information about patients and their attributed Health Professionals including but not limited to patient name, patient date of birth, patient address, patient phone, Health Professional name, identification number, contact information, organization(s), forms of electronic addresses or electronic service information and other associated information as appropriate. The Service will be used in multiple Transitions of Care use cases to send messages to attributed Customer, Health Providers and/or Payers. 6. FEES. 5.2 Additional Terms. Customer may contribute patient and Health Professional information consistent with the terms herein and as otherwise permitted by the Agreement, provided, however, that in no case shall Customer share data in a manner inconsistent with this Use Case, as applicable. To the extent there is an express conflict between the terms herein and the Agreement, the Agreement, as applicable, shall prevail. There will be no fees associated with submission of data to PatientPing for the purpose of this Use Case Agreement. Potential fees between PatientPing to Customer and associated payment terms may be defined in Customer s Statement of Work for this effort. 7. SERVICE LEVEL. The parties desire that the data updates between Customer and PatientPing meet the service levels set forth below: 7.1 Type of Transaction The parties desire that the initial and subsequent data updates occur via file submissions. 7.2 Timeliness of Data Updates The parties desire that the updates be frequent enough to keep the data up-to-date. At a minimum, the updates should be on a monthly basis, although weekly or daily updates may be more appropriate, depending on the rate of change within a particular set of data. 7.3 Network Downtime Notwithstanding Section 7.1, if the parties experience a Network Downtime event, file transfers and/or file processing may error or time-out. If the error occurs during the transfer of the file from Customer to PatientPing, Customer will retransmit the file(s) as soon as practicable. If the error occurs during PatientPing processing of the received files, then PatientPing will reload the file(s) as soon as the outage is resolved. Master Services Agreement Use Case No. 2; Page 2

8. AUDITING. 8.1 Ability to Audit. The parties shall monitor and audit all access to and use of its system related to this Use Case, for system administration, security, and other legitimate purposes consistent with each Party s standard operating procedures. 8.2 Audit Logs.Customer. Customer shall log all audit data required to ensure the successful transfer and troubleshooting of data being submitted to ACRS, including but not limited to the following: (i) all audit data required to ensure successful file transfers, (ii) filename of file(s) with date and time stamp; (iii) date and time the file transmission was sent from Customer to PatientPing; (iv) identity (e.g., unique identifier) of source (owner); (v) the unique message identifier for the file; and (vi) any Notices, failures, or network events that occurred during the file transfer process. (b) PatientPing. With respect to its obligations as a Business Associate, if applicable, PatientPing shall, at a minimum, log the following information: (i) name of file(s); (ii) date and time the file(s) were received from Customer; (iii) identity of system (owner) transmitting the file(s); (iv) identity (e.g., unique identifier) of individual or system transferring the file(s); (v) any Notices, failures, or network events. 8.3 Production of Audit Logs Upon a good faith written request by a party, the nonrequesting party shall produce the requested audit logs, not to exceed five (5) business days from the date of the request to the requesting party or a detailed written explanation of why the requested logs cannot be produced. 8.4 Retention of Audit Logs The parties shall retain audit logs in accordance with any and all requirements set forth in Applicable Laws and Standards, including but not limited to the requirements under the Health Insurance Portability and Accountability Act of 1996, Public Law 104-191, and regulations at 45 CFR Part 160, Part 162, and Part 164, the Michigan Public Health Code, MCL 333.1101 et seq.,, and as otherwise necessary to comply with this Use Case. 9. RESPONSIBILITIES OF THE PARTIES. 9.1 Customer Responsibilities. (a) Customer shall transmit the data to PatientPing as file submissions. (b) Customer shall transmit the data using one of the PatientPing approved secure transport methods, format and content. (c) If the file transfers from Customer to PatientPing fail to transfer successfully in full, Customer shall retransmit, or make provisions to have the files retransmitted. (d) Customer is responsible for the security and protection of Service data. (e) Customer shall transmit data to PatientPing only from organizations that have agreed to participate in this Use Case or from organizations Customer has authorized authority to use. 9.2 PatientPing Responsibilities. (a) (b) (c) PatientPing shall be responsible for protecting Service data. PatientPing shall process data from Customer on a predetermined schedule. PatientPing shall be responsible for successfully loading the data into the Service on a predetermined schedule and notifying Customer of any errors. Master Services Agreement Use Case No. 2; Page 3

(d) PatientPing shall keep record of changes made as a result of new data provided by Customer. 10. OTHER TERMS. 10.1 Data Format, Validation and Transmission Specifications. (a) Data Format 10.1.1.1 The specifications for the files shall be provided as follows: (a) PatientPing shall provide a template to Customer; (b) Customer shall provide a data dictionary for their data file; (c) As otherwise mutually agreed to by the parties, such as in Federated messages; (b) Transmission 10.1.2.1 The specifications for the PatientPing approved secure transport methods are set forth on the MiHIN Shared Services website. (c) Disclaimers 10.1.2.1 Prior to transmitting files to PatientPing, Customer shall ensure that the data is from a Health Professional or provider organization that has entered into all necessary legal and data sharing agreements, such as a Business Associate Agreement, with Customer. 10.1.2.2 Customer shall bear sole responsibility for ensuring that the Health Professional data meets the data integrity, format, security, and timeliness standards prescribed by this Use Case and the Agreement. 10.2 Information for Trial Implementation and Pilots All additional terms and limitations pertaining to Pilots undertaken for this Use Case shall be specified as Exhibits, which amend this Use Case between the Parties upon mutual written agreement to the Pilot terms in any such Exhibit(s). Master Services Agreement Use Case No. 2; Page 4

USE CASE NO. 3 USE CASE FOR SUBMIT DATA TO HEALTH PROVIDER DIRECTORY Use Case Category = Health Provider Directory Use Case Prerequisites = None 1. GOAL.PatientPing seeks to populate the Directory with as much current Health Professional information as is available, and assist Customer in leveraging existing or establishing new capabilities to provide information on their, or their participants, Person Records, Organization Records and any related Affiliations, Electronic Addresses and Electronic Service Information (ESI). Authorized Health Professionals can use the Directory to look up Electronic Addresses and Electronic Service Information to facilitate secure exchange of health information. 2. PURPOSE.The purpose of this Use Case is to define Customer and PatientPing roles and responsibilities as they relate to populating the Directory with Health Professional data and ESI data. 3. USE CASE DIAGRAM. 4. DEFINITIONS. 4.1 Affiliation means the relationship between a Person Record and an Organization Record or between two Organization Records. 4.2 Affiliation Type means the type of relationship or Affiliation between a Person Record and an Organization Record or between two Organization Records. For example employed by, admitting privileges, etc. 4.3 Electronic Address means a string that identifies the transport protocol and end point address for communicating electronically with a recipient. A recipient may be a person, organization or other entity that has designated the electronic address as the point at which it will receive electronic messages. Examples of an electronic address are an email address (Direct via SMTP) or URL (SOAP / XDR). Communication with an electronic address may require a digital certificate. 4.4 Electronic Service Information (ESI) means all information reasonably necessary to define an electronic destination s ability to receive and consume a specific type of information (e.g. discharge summary, patient summary, laboratory report, query for patient/provider/healthcare data). The information should include the type of information (e.g. patient summary or query) the destination s Electronic Address (see definition above), the Messaging Framework supported (e.g. SMTP, HTTP/SOAP), Security information supported or required (e.g. digital certificate) and specific payload definitions (e.g. CCD C32 V2.5). In addition, this information may include labels that help identify the type of recipient (e.g. medical records department). 4.5 Health Professional means any person holding a clinical or non-clinical position within or associated with an organization that provides healthcare or healthcare related services. People who contribute to the gathering, recording, processing, analysis or communication of health information. Examples Master Services Agreement Use Case No. 3; Page 1

include but are not limited to Physicians, Physician Assistants, Nurse Practitioners, Nurses, Medical Assistants, Home Health Professionals, Administrative Assistants, Receptionists, Clerks, etc. 4.6 Health Provider Directory (HPD) ( the Directory ) means the state-wide shared service established by MiHIN Shared Services that contains contact information on Health Professionals, Healthcare Organizations, Electronic Addresses and Electronic Service Information, as a resource for authorized users to obtain efficient, accurate and reliable contact information and securely exchange health information. 4.7 Information Source means any organization that provides information that is added to the Directory. 4.8 Network Downtime means a party is unable to transmit and receive data from the Internet for any reason, including but not limited to the failure of network equipment or software, scheduled or unscheduled maintenance, general Internet outages, and events of force majeure. 4.9 Organization Record means any record in the Directory that primarily relates to a company or other organization (i.e., not a person). 4.10 Person Record means any record in the Directory that primarily relates to an individual person. 5. MESSAGE CONTENT. 6. FEES. 5.1 Primary Use. Populate and maintain up-to-date Health Professional information for the purpose of building a reliable statewide Directory. Customer will provide information about Health Professionals, including but not limited to name, contact information, organization(s), title(s), position(s), health plan network participation and other associated information as appropriate. Authorized Health Professionals can use the Directory to look up Electronic Service Information (ESI), such as Direct Addresses, to facilitate secure exchange of health information. 5.2 Additional Terms. Customer may contribute Health Professional information consistent with the terms herein and as otherwise permitted by the Agreement, provided, however, that in no case shall Customer share data in a manner inconsistent with this Use Case, as applicable. To the extent there is an express conflict between the terms herein and the Agreement, the Agreement, as applicable, shall prevail. There will be no fees associated with submission of data to PatientPing for the purpose of this Use Case Agreement. Potential fees between PatientPing to Customer and associated payment terms may be defined in Customer s Statement of Work for this effort. 7. SERVICE LEVEL.The Parties desire that the data updates between Customer and PatientPing meet the service levels set forth below: 7.1 Type of Transaction The parties desire that the initial and subsequent data updates occur via file submissions. 7.2 Timeliness of Data Updates The parties desire that the updates be frequent enough to keep the data up-to-date. At a minimum, the updates should be on a monthly basis, although weekly or daily updates may be more appropriate, depending on the rate of change within a particular set of data. 7.3 Network Downtime Notwithstanding Section 7.1, if the parties experience a Network Downtime event, file transfers and/or file processing may error or time-out. If the error occurs during the transfer of the file from Customer to PatientPing, Customer will retransmit the file(s) as soon as Master Services Agreement Use Case No. 3; Page 2

8. AUDITING. practicable. If the error occurs during PatientPing processing of the received files, then PatientPing will reload the file(s) as soon as the outage is resolved. 8.1 Ability to Audit. The parties shall monitor and audit all access to and use of its system related to this Use Case, for system administration, security, and other legitimate purposes consistent with each party s standard operating procedures. 8.2 Audit Logs. 8.2.1 Customer. Customer shall log all audit data required to ensure the successful transfer and troubleshooting of data being submitted to the Directory, including but not limited to the following: (i) all audit data required to ensure successful file transfers, (ii) filename of file(s) with date and time stamp; (iii) date and time the file transmission was sent from Customer to PatientPing; (iv) identity (e.g., unique identifier) of source (owner); (v) the unique message identifier for the file; and (vi) any Notices, failures, or network events that occurred during the file transfer process. 8.2.2 PatientPing. With respect to its obligations as a Business Associate, if applicable, PatientPing shall, at a minimum, log the following information: (i) name of file(s); (ii) date and time the file(s) were received from Customer; (iii) identity of system (owner) transmitting the file(s); (iv) identity (e.g., unique identifier) of individual or system transferring the file(s); (v) any Notices, failures, or network events. 8.2.3 Except as provided in the foregoing, PatientPing shall not be obligated to maintain and shall not be responsible for either maintaining records of the content of any file exchange between the Parties or inspecting the content of such files. 8.3 Production of Audit Logs Upon a good faith written request by a party, the nonrequesting party shall produce the requested audit logs, not to exceed five (5) business days from the date of the request to the requesting party or a detailed written explanation of why the requested logs cannot be produced. 8.4 Retention of Audit Logs The Parties shall retain audit logs in accordance with any and all requirements set forth in Applicable Laws and Standards, including but not limited to the requirements under the Health Insurance Portability and Accountability Act of 1996, Public Law 104-191, and regulations at 45 CFR Part 160, Part 162, and Part 164, the Michigan Public Health Code, MCL 333.1101 et seq., the Data Sharing Agreement, and as otherwise necessary to comply with this Use Case. 9. RESPONSIBILITIES OF THE PARTIES. 9.1 Participating Organization Responsibilities. 9.1.1 Customer shall transmit the data to PatientPing as transactions. 9.1.2 Customer shall transmit the data using one of the PatientPing approved secure transport methods, format and content. 9.1.3 If the file transfers from Customer to PatientPing fail to transfer successfully in full, Customer shall retransmit, or make provisions to have the files retransmitted. 9.1.4 Customer is responsible for the security and protection of Directory data. 9.1.5 Customer shall transmit data to PatientPing only from organizations that have agreed to participate in this Use Case. Master Services Agreement Use Case No. 3; Page 3

9.2 HIN Responsibilities. 10. OTHER TERMS. 9.2.1 PatientPing shall be responsible for protecting Health Professional data and Electronic Service Information data. 9.2.2 PatientPing shall process data from Customer on a predetermined schedule. 9.2.3 PatientPing shall be responsible for successfully loading the data into the Directory on a predetermined schedule and notifying Customer of any loading errors. 10.1 Data Format, Validation and Transmission Specifications. 10.1.1 Data Format 10.1.1.1 The specifications for the messages shall be provided in one of the following ways: 10.1.1.2 Transmission (a) Customer shall provide a data dictionary of the message/data file that accompanies the message/data file; (b) PatientPing shall provide a template to Customer (i.e. a spreadsheet template such as the Massachusetts Provider Template modified to Michigan s needs); (c) Based on Provider Directory Schema, provided by PatientPing to Customer; (d) As otherwise mutually agreed by the parties, such as in Federated messages; 10.1.1.3 The specifications for PatientPing approved secure transmission methods are set forth on the MiHIN website. 10.1.2 Disclaimers 10.1.2.1 Prior to transmitting files to PatientPing, Customer shall ensure that the data is from a Health Professional or provider organization that has entered into all necessary legal and data sharing agreements, such as a Business Associate Agreement, with Customer. 10.1.2.3 Customer shall bear sole responsibility for ensuring that the Health Professional data meets the data integrity, format, security, and timeliness standards prescribed by this Use Case and the Agreement. 10.2 Information for Trial Implementation and Pilots All additional terms and limitations pertaining to Pilots undertaken for this Use Case shall be specified as Exhibits, which amend this Use Case between the parties upon mutual written agreement to the Pilot terms in any such Exhibit(s). Master Services Agreement Use Case No. 3; Page 4