Electronic Submission of Medical Documentation (esMD) AoR L2 Harmonization

1. Electronic Submission of Medical Documentation (esMD)AoR L2 Harmonization June 5, 2013

2. Meeting Etiquette • Please announce your name each time prior to making comments or suggestions during the call • Remember: If you are not speaking keep your phone on mute • Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call • Hold = Elevator Music = very frustrated speakers and participants • This meeting, like all of our meetings, is being recorded • Another reason to keep your phone on mute when not speaking! • Feel free to use the “Chat” or “Q&A” feature for questions or comments From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute  NOTE: This meeting is being recorded and will be posted on the esMD Wiki page after the meeting

3. Agenda

4. Schedule • Wednesday, 1 - 3 PM ET: eDoC Workgroup meeting • 1 - 2 PM ET: eDoC Use Case Meeting • 2 - 3 PM ET: eDoC Structured Data SWG Meeting • Friday, 2 - 3 PM: eDoC Structured Data SWG Meeting

5. ED Data Type • This data type is for data primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard (e.g., XML-signatures.) Instead of the data itself, an ED may contain only a reference. • Supports Compression, and uses “Thumbnail” • Thumbnail can be used to describe the signature • Solves Unstructured Body problem

6. RIM Element - SignatureText • Does not have to be a reference, can use any valid MIME type (e.g., XML) • Can be associated with each participant • Can be used in the CDA Header • New Participant Type • XAdES-LT for signatures/SAML

7. Certificate Signing (CRLs) Basic Certificate Fields (CRL) • tbsCertificate • version • serialNumber • signature • issuer & issuerUniqueID • validity • notBefore & notAfter • subject, subjectPublicKeyInfo & subjectUniqueID • signatureAlgorithm • signatureValue

8. Certificate Signing (OCSPs) • Basic Response Message Requirements (OCSP). A definitive response message must contain, at a minimum: • Protocol version of the response syntax • Name of responder • Responses for each of the certificates in a request • Signature algorithm OID • Signature computer across the hash of the response • For each of the certificates in a request, the response must contain: • Certificate ID • Certificate status (i.e., “good,” “revoked,” “unknown”) • Response validity interval

9. SAML Overview - Participants • At a minimum, SAML exchanges take place between system entities referred to as a SAML asserting party, which makes SAML assertions, and a SAML relying party, which uses assertions it has received. Most SAML assertions are in regards to a Subject about whom the assertion is being made. • When a SAML asserting or relying party makes a direct request to another SAML entity, the party making the request is called a SAML requester, and the other party is referred to as a SAML responder. • A relying party's willingness to rely on information from an asserting party depends on the existence of a trust relationship with the asserting party. • SAML system entities can operate in a variety of SAML roles which define the SAML services and protocol messages they will use and the types of assertions they will generate or consume. • Example SSO Roles: • Principal – Subject of Assertion • Identity Provider – SAML asserting party • Service Provider – SAML relying party

10. SAML Overview - Assertions An assertion contains some basic required and optional information that applies to all its statements, and usually contains a subject of the assertion, conditions used to validate the assertion, and assertion statements. • Authentication statements: These are created by the party that successfully authenticated a user. At a minimum, they describe the particular means used to authenticate the user and the specific time at which the authentication took place. • Attribute statements: These contain specific identifying attributes about the subject (for example, that user “John Doe” has “Gold” card status). • Authorization decision statements: These define something that the subject is entitled to do (for example, whether “John Doe” is permitted to buy a specified item).

11. SAML Overview – Confirmation Method The SubjectConfirmation element provides the means for a relying party to verify the correspondence of the subject of the assertion with the party with whom the relying party is communicating. The Method attribute indicates the specific method that the relying party should use to make this determination. SAML 2.0 accounts for three different security scenarios by defining three values for the Method attribute of the SubjectConformation element, these are • holder-of-key – the attesting entity demonstrates knowledge of specific key information to use the assertion (and thereby lay claim to some relationship with the subject within). • sender-vouches - the relying party has an existing trust relationship with the attesting entity. The attesting entity vouches for the subject of the assertion. • bearer - any party that bears the Assertion may use the assertion.

12. SAML Overview – Delegationof Rights Artifact XML Example Switch to Author of Record L1 IG to highlight the following sections: • 8.3: Delegation of Rights Artifact • 8.4: Delegation Agent Signature for Delegation of Rights Artifact

13. AoR L2 Data Model Elements Review Switch to Excel spreadsheet