XDS - Cross-Enterprise Document Sharing


Published on

Chris Lindop
GE Healthcare,
IHE-International, IHE-Radiology Co-Chair
(Wednesday, Interoperability Reference Architecture Workshop)

Published in: Health & Medicine
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Slide with animation: see in presentation mode.Note that multiple Repositories can be linked to one Registry.
  • Document Replacement Option - ability to submit a document as a replacement for another document already in the registry/repositoryDocument Addendum Option – ability to submit a document as an addendum to another document already in the registry/repositoryDocument Transformation Option – ability to submit a document as a transformation of another document already in the registry/repositoryFolder Management Option – ability to: Create a folderAdd one or more documents to a folder Basic Patient Privacy Enforcement OptionDocument Source ability to:Populate the confidentialityCode in the document metadataEnforce the XDS Affinity Domain PolicyDocument Recipient ability to:Understand and enforce the Patient Privacy PoliciesCoerce the confidentiality code in the metadata from Source to Recipient codesAbide by the XDS Affinity Domain Policies represented by the confidentialityCode in the document metadataBasic Patient Privacy Proof OptionDocument Consumer ability to:Query for “Approved” Patient Privacy Acknowledgement Documents by document classRecognize the eventCodeList from the resulting XDS Metadata (no requirement to retrieve Patient Privacy Acknowledgement Document content)
  • ATNA - Audit Trail and Node Authentication
  • Before any technology can be applied to enforcing Security or Privacy, an organization must define the Security and Privacy Policies that they are going to need enforced. The Profiles from IHE are designed to be policy agnostic, meaning they can enforce almost any policy. In this way there is no constraint to implement a single policy.These policies are built up of many layers of external policies. Starting with the highest level policies in the International community, such as the Organization for Economic and Co-operation and Development (OECD). This highest layer should also respect human rights, ethics, and norms. The next layer down are those of the country, such as HIPAA in the USA, EC95/46 in Europe, and Act 57 in Japan.The next layer is those policies from the specific industry domain, in this case Healthcare. Some of the sources for this layer comes from the country, but they also come from medical professional societies. And finally the Enterprise needs to consider good organizational policies such as backup and recovery policies.This is clearly an overview of all the potential influences on policies, but the important thing to take away is that policies must be created and written before technology is discussed. This is not to ignore the very fact that sometimes technology limits the policies, such as we will get into later in this presentation around Privacy Consents.
  • Security is best approached using a Risk Assessment model. That is to determine the risks to security; that is risks to Confidentiality, Integrity and Availability. As part of a Risk Assessment the Risk level is measured in terms of a combination of the likelihood of occurrence (probability) and degree of impact (positive or negative) of an anticipated event. Imagine a “hole in the roof” scenario, the risk is that weather (the threat) could cause damage to components inside the building as well as the building itself. As long as the weather report shows that there is little chance of precipitation, our risk level is low. However, this risk increases as the likelihood of precipitation increases. Since we cannot control the threat of precipitation, we mitigate our risk by changing the vulnerability; we fix the hole in the roof. The cost of fixing the vulnerability is much less, in this case, than the damage rain or snow would cause.Examples of Threats -- natural disaster, random accident, disgruntled employee, employee snooping, external indiscriminate hacker, external motivated hacker, external highly motivated and highly funded)Examples of Vulnerabilities – access without user identification, access without user authentication, user accessing data that they don’t need to know for their job, open network interface, Likelihood is an assessment of how likely that threat is going to exploit that vulnerability. Typically a gross assessment of High, Medium, and LowImpact is an assessment of how much damage (harm) would result if that threat exploited that vulnerability (regardless of how unlikely). Typically a gross estimate of High, Medium, Low
  • Here are some ready made Risks that are typically thought of in Healthcare. Clearly not a complete list, clearly missing a large amount of information. The list is given as a sample of Risks across the spectrum of what an Interoperability Profile can address (Note risk of electrical failure is not something an interoperability profile can address, but clearly is a risk that the organization must address)
  • Another thing that varies from organization to organization is the policy they apply to accountability. There are two different types of accountability models that usually are mixed. In the Access Control Model the users are simply prevented from doing anything that they should not do.In the Audit Control Model the user is empowered to go beyond what they are minimally to do for their job, because there are situations where they may be called upon to do more. For example where doctors should only access the patients records that they are assigned to, but are given access to all patients so that they can more quickly assist with a consult, urgent care, or even an emergency. In healthcare there is typically a mixture that is more Audit Controls centric.In all models, the janitor is still prevented from seeing clinical data as there is no reasonable expectation that the janitor will ever need to.
  • This table shows how the IHE Security and Privacy Profiles affect the security and privacy domain. Where a checkmark is a strong contribution by the Profile and a dot is a minor contribution (or supporting relationship). The first 5 Profiles will be further discussed in this presentation.PWP and HPD are discussed elsewhereDocument Encryption are not yet final so are not discussed hereWhich control should we use to prevent the wrong people from looking at PHI?Which profiles would you use in an investigation of a potential incident?Which profiles would inform an accounting of disclosures?
  • Time Server– From the Consistent Time Profile – provides a consistent time for all audit logs in a given organizationSecure Node – a complete hardware and software system that is considered a in whole to be onemay be made up of multiple computers, but is one distinguishable systemExample: MRI – made up of many components and computers, may even be made up of discrete physical cabinetsExample: EHR – whole system considered as one including all workstations and supporting serversExample: EKG device – single small medical deviceSecure Application – a software component that is expected to be integrated into a larger system. Where this software component is responsible for securing any communications it is controlling, initiating, receiving; responsible for any controlling access that it is responsible for; and responsible for logging any security events that it is in control ofNote this means that it is simply not responsible for something that is out of it’s control (for example: auditing of the system startup event, or user-login event)Example: a network service that requires to be integrated into a database farmExample: A software application that must be installed onto a workstationAudit Record Repository – Receives the Record Audit Event transaction. A system implementing this actor will typically process, report, record, alert, forward, and in any other way process the security events.
  • This diagram shows in more detail how the Audit Record Repository within Clinic A will record all the events detected and recorded by the EMR within that clinic. This Audit Record Repository system will filter out the audit log events that are associated with the HIE and forward them to the Audit Record Repository in the HIE to be combined with all the other events forwarded and detected within the HIE.
  • SAML Assertion contains claims about the user and the session the transaction initiates in:The addition of the SAML assertion is contained within the additional WS-Security headerThis does not affect the original soap header or body.
  • There is only one formal transaction (ITI-40), and this transaction is a modification of <any> web-services based transaction. The X-Service User is grouped with <any> other Actor that is a SOAP requester. The X-Service Provider is grouped with <any> other Actor that is a SOAP responder. In that ITI-40 requires that the WS-Security header be added to the SOAP message and contain a Binary token of that is the SAML 2.0 Identity Assertion.The User Authentication Provider is shown as there needs to be some actor that does the user authentication. When EUA or PWP are used to authenticate the user their specific Authentication Provider actor fits here.The X-Assertion-Provider is a virtual actor that provides the Assertion to the X-Service User. This Actor is typically tightly coupled with the User Authentication Provider through proprietary means. The Get X-User Assertion transaction is not profiled in the XUA profile as there is no special behavior required; this could be implemented through internal transactions, SAML 2.0 Protocol, or WS-Trust. The “other Assertion transactions” is shown as some X-Service Providers may choose to use SAML 2.0 Protocols or WS-Trust; but there is no special behavior for the XUA profile here.
  • First Display: An EHR that has local Patient Data, Local Audit Log, Local User Authentication and implements a XDS Consumer. The XDS Registry is shown with an ATNA audit record repository.On Click: Add the XUA Transaction, which modifies the original XDS Consumer to include the SAML Assertion describing the user and their local context relevant to the transaction. This SAML Assertion is derived from the original User Authentication. At the XDS Registry the Audit log entry now would include the user identity, and access controls may be enhanced.
  • The user is authenticated, typically as part of their long-term session. At some point the system queries the HIE and includes a XUA assertion along with the XDS Query parametersAn Access Control service intercepts the transaction and inspects the XUA assertion and XDS Query parametersThe Access Control service looks for any OPT-OUT BPPC documents, If the patient has agreed to OPT-OUT; then the access control service responds with zero-results-found. If there is no OPT-OUT, then the query is forwarded to the Document Registry that processes it normallyAnd returns the normal resultsIt is possible that the return results could be further filtered based on the ROLE of the user, but that is not shown here.
  • An Access Control decision is made given many factors. For example:“Context Domain” System the user is using -- ATNAWhat is the identity of the system is the user using -- ATNA – Authenticate NodeIs the communications encrypted and integrity protected -- ATNA – secure communicationsWill security audit logs be generated for the actions -- ATNA – Audit LogPatient ContextWho is the Patient -- PIX/PDQ/XCPDWhat are the Patient Preferences / Consent -- BPPC“Subject Domain” i.e. User Context -- XUAWho is the user -- EUAWhat roles does the user have (functional and structural) -- PWPWhat is the user trying to do – PurposeOfUseRelationship to Patient – Consent AuthorizationAdditional factors such as Emergency-Mode or Break-Glass“Resource Domain” i.e., Object Context -- XD* MetadataWhat is the specific object -- XD* Metadata - uniqueIDWhat is the data sensitivity classification -- XD* Metadata – confidentialityCodeWho is the author of the object -- XD* Metadata - AuthorWhat type of a document is the object -- XD* Metadata – classCodeWhere did the document come from -- XD* Metadata – facility type code
  • This table shows a Role-Based-Access-Control map. The Rows are made up of example “Functional Roles”, these are roles that any user could be assigned to based on their job classification. The Columns are examples of “Sensitivity” classifications, and the HL7 confidentialityCode is shown that might be used for each. In the table an X indicates that the specific Role would have access to the kind of data classified with that Sensitivity or confidentialityCode.This table might represent what is allowed if the patient has chosen an OPT-IN Patient Privacy Policy
  • This is the same table as before, except this one shows what the table might look like if the Patient has chosen an OPT-OUT. In this case the table has an additional Permission that if a user holds this permission they are allowed to “break-glass” and if they do that then access would be allowed.
  • This slide shows that IHE has not constrained where Access Controls are enforced, and have enabled that Access Controls can be enforced in many places.This is the classic Access Control where the Requesting System (e.g. the system implementing the XDS Document Consumer) enforces all Access Controls. In this example the XDS Registry is only assuring that it is communicating only with a system that it explicitly trusts (using ATNA Secure Communications). This does assure that the XDS Registry is not accessed by rogue systems, but is only system level Authentication. This model is the most simple to build, especially if it is leveraging the Access Controls that might already be available in the Requesting System.In this diagram the Responding System (e.g XDS Registry) is enforcing the Access Controls. This is enabled by including the XUA identity assertion. This model can gain through having the Access Controls implemented in one place, thus saving on complexity and assuring consistency. This model however suffers in that it is much harder to handle use-cases where the context at the client is complex. Such as when there is a case that would normally be denied, but under emergency-mode would be authorized.In the third diagram is a more balanced environment. Where gross access controls are enforced at the Responding System (e.g. XDS Registry), and more fine-grained controls are enforced at the Requesting system (e.g. XDS Document Consumer)Note: It is often not recognized that in Healthcare, especially in cross-organizational transactions that the data communicated will be copied for future use. Thus what ever data is returned to the Requesting system (e.g. XDS Document Consumer) will likely be copied and thus future access control decisions to that copy are in the control of the Requesting system.Note: That Access Controls can actually take place in a trusted intermediary that is not a component of the Requesting or Responding system. This is a much more difficult system to deploy.
  • This table shows how the IHE Security and Privacy Profiles affect the security and privacy domain. Where a checkmark is a strong contribution by the Profile and a dot is a minor contribution (or supporting relationship). The first 5 Profiles will be further discussed in this presentation.PWP and HPD are discussed elsewhereDocument Encryption are not yet final so are not discussed hereWhich control should we use to prevent the wrong people from looking at PHI?Which profiles would you use in an investigation of a potential incident?Which profiles would inform an accounting of disclosures?
  • Separate PWP from HPD
  • Yellow Pages Lookup: A patient is referred to an endocrinology specialist for an urgent lab test. The referring physician needs to get the contact data of close-by endocrinologists in order to ask whether one of them can perform this test in their own lab. The patient prefers a female endocrinologist who can converse in Spanish regarding medical information. Current Situation: The physician has a card catalog with names of local endocrinology specialists. Office staff calls each in turn to ask if they are available to run the test. Each is questioned regarding their availability and ability to speak Spanish. Presumably the card catalog name would indicate the Gender of the physician.Use of HPD: As a Provider Information Consumer, a computer application running in the office of physician is used to lookup provider information. The office staff enters the specialty, geographic indicators like zip code, city or state, language and gender. The application sends a query request to the Provider Information Directory which returns information about every provider satisfying the search, in particular the physical and electronic address, and contact information. An appropriate endocrinologist is chosen based on the attributes included in the response, an appointment is made, and the referral documentation is electronically sent to the physician using the electronic address specified.Query providers and their associations for Social Services Disability Determination: A citizen, as a claimant, applies for disability benefits from the Social Services Department. This disability is due to a medical condition. In order to receive benefits, an application must be made, medical evidence must be provided, and a determination made on the claim.The claimant, in the claim, includes a list of the providers seen (names or practices) and other medical services he has obtained, related to his disability. The Social Services department needs to gather medical evidence from all the reported providers, and wants to direct their queries to the specific providers mentioned. For that purpose, the Social Services department needs to obtain the provider‘s contact information, electronic address, and provider‘s relationship with other organizations such as HIE, for each of the providers supplied by the claimant.Current Situation: The Claims Processor searches through an electronic file or card catalog of providers to look up providers that the claimant has named. If the Claims Processor finds aprovider in the file, or catalog, the Claims Processor faxes a request for medical evidence along with a release form signed by the patient. Often research has to be done before a fax number can be determined (phone calls need to be made, or additional contact information needs to be identified). If the Claims Processor does not find a provider in the file, or catalog, extensive research may need to be done before the correct provider is identified. This must be done for every provider on the claim. Because limited or outdated information is often given by the claimant, identifying the provider can take quite a long time, substantially delaying the process and the disability determination.Use of HPD: The disability software application collects healthcare services provider data froma list of filed claims. Acting as Provider Information Consumer, this application sends a query request to the Provider Information Directory for each provider on the claim. The Provider Information Directory returns information about the providers, in particular, the electronic address where the Medical Evidence Requests (MERs) are serviced for that provider. Working with the System Directory for Document Sharing (SDDS) profile to identify the appropriate electronic end point, an appropriate MER request is sent to the physicianEmergency Responders Identification in planning for an emergency event: Emergency response planning requires the identification of potential providers who can assist in an emergency. Providers must meet specific credentialing criteria and must be located within a reasonable distance of the emergency event. Current Situation: The planners of the emergency event search for potential provider participants by manually initiating searches on the internet, contacting associations for candidates, and looking through the local yellow pages. Once phone number contact information for these providers is identified, contact is initiated. Use of HPD: Using HPD, an emergency planning team member can initiate a single search for a list of providers based on specialty, geographic indicators like zip code, city or state, and other criteria. The Provider Information Directory returns information about every provider satisfying the search, including e-mail addresses. An e-mail can be generated to all identified providers requesting participationProvider Authorization and lookup during an emergency event: During Hurricane Katrina, health care volunteers were turned away from disaster sites because there was no means available to verify their credentials. At an emergency site, the Provider Information DirectoryCertificate Retrieval: National regulations in many European countries require that an electronically transmitted doctor‘s letter be encrypted in a way that only the identified receiver is able to decrypt. In order to encrypt the letter, the sender has to discover the encryption certificate of the receiver.Language Retrieval: An individual who only speaks Italian requires healthcare services at an Outpatient Clinic. That individual would like to be able to communicate with the Clinic personnel, if at all possible. The individual or his caregiver needs to determine which clinic supports Italian and provides the service that is required
  • Publisher - source of the information to which there may be a subscription. Sends Publish transaction and when the publish/subscribe pattern is applied to an existing IHE profile, in most cases it will be grouped with an existing IHE actor. Notification Broker – keeps track of all subscriptions, and based on the information received in a Publish transaction it sends notifications to the appropriate Notification Recipients. Receives Subscribe transaction, which represents subscription requests, modifications, and cancellations. It also keeps track of the time limits of subscriptions. Subscriber - initiates, modifies, and terminates subscriptions on behalf of a Notification Recipient. It is the sender of the Subscribe transaction, and it may be servicing any number of Notification Recipients. Notification Recipient - receives the notification about a published event, when the subscription filters specified for this Notification Recipient are satisfied.
  • Various combinations of actors are possibleIt is also possible to chain these groups to achieve cascading notifications
  • Also shown on the diagram (for illustration of possible use):XDS Document Source or XDS Document Registry may be grouped with PublisherXDS Document Consumer may be grouped with Notification Recipient
  • Slide with animation: see in presentation mode.
  • XDS - Cross-Enterprise Document Sharing

    1. 1. XDSCross-Enterprise Document Sharing
    2. 2. Health Document Exchange Options Flexible Infrastructure XDS XDS INFRASTRUCTURE M8354673993 Publish L-716 A87631 14355 Query/Retrieve XDR Existing Reliable Send to Messaging System Send to Interchange Media XDM Read Write Including Email XCA XCA INFRASTRUCTURE M8354673993 L-716 A87631 14355 Query/Retrieve2
    3. 3. What is XDS ? The Cross-Enterprise Document Sharing (XDS) IHE Integration Profile facilitates the registration, distribution and access across health enterprises of patient electronic health records It provides a standards-based specification for managing the sharing of documents between any healthcare enterprise3
    4. 4. XDS Affinity Domains Group of healthcare enterprises that have agreed to work together using a common set of policies and XDS-based infrastructures for sharing patient clinical documents. Some examples are: Regional community of care Nationwide EHR Specialized or disease-oriented (cardio, diabetes, oncology) Government-sponsored or federation of enterprises Insurance provider supported communities XDS profile is designed to accommodate a wide range of policies on: Patient identification and consent Controlling access to information Format, content, structure, and representation of clinical information4
    5. 5. Use Cases Patient Care Summary (e.g. within a region)  Publishing of Care Summaries by providers  Access to patient‟s Care Summary in an emergency eReferral between primary and secondary care providers Sharing of radiology reports and images between facilities Sharing of laboratory reports by clinical laboratories with ordering physicians and other care providers ePharmacy between community pharmacy and ambulatory physicians5
    6. 6. Main Systems and Responsibilities A document Repository is responsible for storing documents in a transparent, secure, reliable and persistent manner and responding to document retrieval requests. A document Registry is responsible for storing information or metadata about those documents so that the documents of interest for the care of a patient may be easily found, selected and retrieved irrespective of the repository where they are actually stored. Any IT system (e.g. point of care) may act as a Document Sources or Document Consumers submitting documents for registration, or querying/retrieving relevant documents. Notes: Analogous to a library (book repository) and catalog/index The Registry does not have access to the documents – an important separation from security and privacy perspective Multiple Repositories can be linked to one Registry6
    7. 7. XDS Flow and Interactions XDS Document (Metadata): Registry 3. Consumers search Consumer Class for documents with Patient Id specific information Author Facility Date of Service … 2. Repository registers the documents metadata and pointer with the Registry 4. Consumers retrieve selected documents from Repository (-ies) 1. Sources post document packages Source of to the Repository Documents Repository7
    8. 8. XDS Transaction Diagram Patient Identity Source Patient Identity Feed [ITI-8] Patient Identity Feed HL7v3 [ITI-44] Registry Stored Query [ITI-18] Document Document Registry Consumer Register Document Set-b [ITI-42] Retrieve Document Set [ITI-43] Document Document Source Provide&Register Repository Document Set-b [ITI-41]Integrated Document Source/Repository8
    9. 9. XDS Actors Document Source – producer and publisher of documents, responsible for sending documents and their metadata to a Document Repository actor Document Repository is responsible for both the persistent storage of these documents as well as for their registration with the appropriate Document Registry Document Registry maintains metadata about each registered document and a link to the Document in the Repository where it is stored. Responds to queries from Document Consumer actors about documents meeting specific criteria. Document Consumer queries a Document Registry for documents meeting certain criteria, and retrieves selected documents from one or more Document Repository actors Patient Identity Source provides unique identifier for each patient and maintaining a collection of identity traits. This facilitates the validation of patient identifiers by the Registry Actor in its interactions with other actors Integrated Document Source/Repository combines the functionality of the Document Source and Document Repository actors into a single actor that does not expose the Provide and Register Document Set transaction9
    10. 10. XDS Transactions (1) Provide and Register Document Set – For each document in the submitted set, the Document Source Actor provides both the documents as an opaque octet stream and the corresponding metadata to the Document Repository. The Document Repository is responsible to persistently store these documents, and to register them in the Document Registry using the Register Documents transaction. Register Document Set allows a Document Repository Actor to register one or more documents with a Document Registry, by supplying metadata about each document to be registered. This document metadata will be used to create an XDS Document Entry in the registry.10
    11. 11. XDS Transactions (2) Patient Identity Feed conveys the patient identifier and corroborating demographic data, in order to populate the Document Registry with patient identifiers that have been registered for the XDS Affinity Domain. (At least one of the options [ITI-8] or [ITI-44] must be supported.) Registry Stored Query is issued by the Document Consumer Actor to a Document Registry. It will return registry metadata containing a list of document entries found to meet the specified criteria including the locations and identifier of each corresponding document in one or more Document Repositories. Retrieve Document Set – initiated by a Document Consumer. The Document Repository shall return the document set that was specified by the Document Consumer.11
    12. 12. XDS Document Content TypesXDS profile is content agnostic – it can be used with avariety of document types, including: XDS-SD: Scanned document, plain text or PDF/A, in HL7 CDA R2 format XDS-MS: Medical summary in HL7 CDA format XDS-I: Radiology report in plain text of PDF format, or reference to a collection of DICOM SOP Instances in a manifest document in the DICOM Key Object Selection format Also supported are many other document content profiles specified by the IHE Patient Care Coordination, Laboratory, Cardiology, Pharmacy Technical Frameworks12
    13. 13. XDS – Actors and Options Actors Options Reference Document Replacement ITI TF-1: 10.2.1 Document Addendum ITI TF-1: 10.2.2Document Source Document Transformation ITI TF-1: 10.2.3 Folder Management ITI TF-1: 10.2.4 Basic Patient Privacy Enforcement ITI TF-2b: RepositoryDocument Registry Patient Identity Feed ITI TF-2a: 3.8Patient Identity Source Patient Identity Feed HL7v3 ITI TF-2b: 3.44 ITI TF-2a: Basic Patient Privacy EnforcementDocument Consumer ITI TF-2b: Basic Patient Privacy Proof ITI TF-2a:
    14. 14. Standards Used ebRIM OASIS/ebXML Registry Information Model v3.0 ebRS OASIS/ebXML Registry Services Specifications v3.0 ITI TF-2x: Appendix V  WS-I Profiles BP 1.1, BSP 1.0  WS-* Specifications (SOAP 1.2, MTOM/XOP)14
    15. 15. Metadata ObjectsMetadata is data stored in the RegistryDocument - represents a real documentSubmission Set - included in allsubmissions to document the submitted“package”Folder - for grouping documents(directory metaphor)Association - Links other objects together
    16. 16. Object StructureEach Metadata Object has internalstructureebRIM standard coding used (XML)
    17. 17. Single Document SubmissionSubmission Association Document Set (HasMember)Envelope Contents Metadata
    18. 18. Submission Set AttributesAuthor Coded elements person, role, specialt  contentType (type of y, institution clinical activity)Title, comments, s Identifiersubmission time  Patient ID, SourceAvailability Status ID, Unique ID, UUID Submitted or Approved
    19. 19. Document AttributesAuthor Identifiers Person, role, specialty, in  Patient ID, Unique stitution ID, UUIDLegal Authenticator DemographicsTitle, comments, creation time, service  Source Patientstart/stop time ID, Patient DemographicsAvailability Status Submitted, Approved, De precated
    20. 20. Document Attributes (cont)Coded Values Technical Details Kind of Document  MIME Type • Class Code (general catagory)  Format Code (more • Type Code (more detail) detail) Event Code (main clinical  Size event)  Hash Healthcare Facility Type Practice Setting Type  URI Confidentiality Code  Language
    21. 21. Document Attributes (cont) Document Metadata points to Document in Repository
    22. 22. Association AttributesType HasMember RPLC (Replace) APND (Appends) XFRM (Transformation) SignsSubmissionSetStatus Original or ReferencePointers sourceObject, targetObject
    23. 23. Multiple Document Submission Document Association (HasMember)Submission Set Association (HasMember) Document
    24. 24. Document ReplacementSubmission Document Set Association Status = Approved Status = Approved (HasMember) Status = Deprecated Association (RPLC)Submission Association Document Set (HasMember) Status = Approved Status = Approved
    25. 25. Digital SignatureClinical Document Stored in Repository Indexed in RegistryDigital Signature (Document) Stored inRepository Indexed in RegistryHow is Signature “attached” to ClinicalDocument?
    26. 26. Digital Signature (DSG Profile) Submission Clinical Association Set (HasMember) Document Status = Approved Status = Approved Association (Signs) Submission Signature Association Set (HasMember) Document Status = Approved Status = Approved
    27. 27. XDS Metadata handling Patient Identity Source Patient Identity Interprets Feed Query Documents Stores Document Document Registry ConsumerGenerates Register Provide and Document Set Register Retrieve Document Set DocumentDocument Document Source Repository Adds
    28. 28. Affinity DomainSet of organizations/systems organizedaround a single RegistryCommon set of CodesSingle Patient ID DomainInvolves business and legal agreementsSecurity model/agreements
    29. 29. XDS Example Enterprise Imaging Center PCP Enterprise Repository Repository Enterprise Cross- Hospital A Enterprise Document Repository Registry (XDS) Emergency Room Enterprise Repository PatientAdmin Hospital B
    30. 30. XDS: Standards UsedElectronic Business Internet Standards HTML, HTTP, Standards ISO, PDF, JPEG … ebXML, SOAP … Healthcare Content Standards HL7 CDA, CEN EHRcom HL7, ASTM CCR DICOM …
    31. 31. XDS: Standards UsedXDS Infrastructure StandardsOASIS/ebXML Registry Information Model v2.0 • Basis of XDS Registry Information Model Registry Services Specifications v2.0 • Registry Services Messaging Services Specifications v2.0 • Offline protocolsISO/IEC 9075 Database Language SQL Registry Query LanguageSOAP with Attachments Protocol for communication with XDS Registries and RepositoriesSHA-1 [FIPS 180-1] Document Hashes
    32. 32. XDS: Standards UsedXDS Infrastructure Standards (cont)HL7 Version 2.3.1 Messages for Patient Identity ManagementHL7 Version 2.5 Datatypes for XDS Registry Attribute valuesHL7 CDA Release 1 XDS Document concept definition Source of XDS Document Entry AttributesDICOM, ASTM CCR, HL7 CDA Release 2, CENEHRcom Sources of XDS Document Entry Attributes
    33. 33. XDS: Standards Used• XDS Infrastructure Standards (cont) HTTP MIME  Protocol for Retrieve  Document Type codes Document UTF-8  Online SOAP bindings  Encoding of Registry SMTP Attributes  Offline ebMS bindings IETF  Language Identifiers
    34. 34. XDS: Standards UsedTwo “categories” of standards used XDS Content XDS Infrastructure
    35. 35. XDS Content ProfilesOutside scope of XDS; layer on top of XDSContent Profiles Document use cases and translation of document content into registry metadata Publishable separately Generated (mostly) by other committees (PCC, Radiology, Lab etc)Of concern only to Document Source andDocument Consumer actorsBase standards for Content Profilesinclude: HL7 CDA, DICOM, ASTM CCR
    36. 36. Security and Privacy Considerations All actors be grouped with a ATNA Secure Node Actor or Secure Application Actor resulting in each node (systems supporting XDS actors) of the XDS Affinity Domain should have audit and security mechanisms in place Transactions between different secure nodes that use ATNA are encrypted Each XDS Transaction will result in an audit event record sent to an ATNA Audit Record Repository Actor from each XDS actor Timestamp consistency is provided by Consistent Time (CT) profile36
    37. 37. XDS Workflow Health Information Exchange Network PIX or PDQ PIX or PDQ Query Patient Demographics Supplier Query Patient Identity XRef Mgr A87631 M8354673993 PMS M8354673993 14355 L-716 14355 L-716 A87631 ED Application Physician Office Document Document Registry Repository PACS Document Repository EHR System Query Document Register Document Provide & (using Patient ID) (using Patient ID) Register PACS Retrieve Document Maintain Lab Info. Record Audit Time System Event Maintain Time Teaching Hospital Maintain Community Clinic Time Audit record repository Time server ATNA CT Record Audit Event XDS Affinity Domain37
    38. 38. XDS Query Catalogsupported by Stored Query
    39. 39. Stored QueryDefines a collection of queries Name Function/purpose they serve Parameters they acceptMust be supported by all XDS Registries!
    40. 40. Query TypesPrimary queries Based on Patient IDSecondary queries Based on registry identifiers
    41. 41. Primary QueriesFindDocuments Find documents for a patientFindSubmissionSets Find submission sets for a patientGetAll Get everything known about a patientEach have parameters to restrictdocuments „found‟
    42. 42. Secondary QueriesGetDocuments Given the ids of the documentsGetFolders Given the ids of the foldersGetAssociations Related to a given document/folder/submission set
    43. 43. Secondary Queries (cont)GetDocumentsAndAssociations Combines GetDocuments and GetAssociations queriesGetSubmissionSets For a collection of documents and/or foldersGetSubmissionSetAndContents Given the id of the submission set, return its contents
    44. 44. Secondary Queries (cont)GetFolderAndContents Given the id of a folder return the folder and its contentsGetFoldersForDocument Given the id of a document return all folders that „contain‟ the documentGetRelatedDocuments Given the id of a document return all documents that are related to the document through an association
    45. 45. XDS Configurations Understanding how the actors work together
    46. 46. XDS Transaction Diagram Patient Identity Source Patient Identity Feed Query Documents Document Document Registry Consumer Register Provide and Document Set Register Retrieve Document Set DocumentDocument Document Source Repository
    47. 47. Source/Consumer GroupingA single workstation that can submit andaccess content.
    48. 48. XDS Transaction Diagram Patient Identity Source Patient Identity Feed Query Documents Document Document Registry Consumer Register Provide and Document Set Register Retrieve Document Set DocumentDocument Document Source Repository
    49. 49. Registry/Repository GroupingAffinity Domain could offer a centralRepository along with Registry to servefacilities that do not have local Repository.
    50. 50. XDS Transaction Diagram Patient Identity Source Patient Identity Feed Query Documents Document Document Registry Consumer Register Provide and Document Set Register Retrieve Document Set DocumentDocument Document Source Repository
    51. 51. Source/Repository GroupingA source of documents could be an existing EHR which Registers documents in Registry Allows document retrieval via Retrieve Document transaction Stores information internally in non- document formats Must manage document persistence
    52. 52. What is a Document?Content/Documents have 3 formats: Storage Transfer/interface DisplayXDS constrains the transfer/interfacethrough Content Profiles Use of IHE published Content Profiles is a local choice. It is not required by XDS.Transfer/interface formats are chosenlocally by Affinity DomainIHE only makes recommendations
    53. 53. Security and Privacy Overview What IHE Delivers
    54. 54. Agenda Overall Security and Privacy controls Consistent Time (CT) Audit Trails and Node Authentication (ATNA) Enterprise User Authentication (EUA) Cross-Enterprise User Assertion (XUA) Document Digital Signature (DSG) Basic Patient Privacy Consents (BPPC) Access Control Gaps ConclusionNovember 25, 2011 54
    55. 55. Layers of Policies Examples International OECD Guidelines on Transborder Flows Profiles enables / enforces Country-Specific US-HIPAA; EU-EC95/46; JP-Act 57 - 2003 Horizontal Industry Medical Professional Societies Enterprise Backup and RecoveryNovember 25, 2011 55
    56. 56. Risk ScenarioIn this scenario:• The vulnerability is the hole in the roof• The threat is the rain cloud• Rain could exploit the vulnerability The risk is that the building and equipment in the building could be damaged as long as the vulnerability exists and there is a likely chance that rain will fall.November 25, 2011 56
    57. 57. Security Mis-Use-Cases Prevent Indiscriminate attacks (worms, DOS) Normal Patient that accepts XDS participation Patient asks for Accounting of Disclosures Protect against malicious neighbor doctor Patient that retracts consent to publish Provider Privacy Malicious Data Mining Access to Emergency data set VIP (movie star, sports figure) Domestic violence victim Daughter with sensitive tests hidden from Parent Sensitive topics: mental health, sexual health Legal Guardian (cooperative) Care-Giver (assists w/ care)November 25, 2011 57
    58. 58. Accountability ModelsAccess Control model – Prevention Strong controls on User Identification and Authentication Strict Role-Based-Access-Control  No one is given any more access rights than they minimally need Typical in a BankAudit Control model – Reaction Strong control on User Identification and Authentication Relaxed Role-Based-Access-Control  Emphasis on Training and Awareness of oversight  Told what you are normally allowed to do  Empowered to do what is right when necessary Audit Logs are inspected regularly Abuse is detected and acted uponHealthcare: Typically mixture w/ emphasis on Patient SafetyNovember 25, 2011 58
    59. 59. Profiles mapped to Security & Privacy Controls Audit Log Authentication Identification and Control Data Access Secrecy Data Integrity Non-Repudiation Patient Privacy Security & Privacy Controls ProfileIHE Profile IssuedAudit Trails and Node Authentication 2004 √ √ √ √ √ √ √Consistent Time 2003 √ ∙ √Enterprise User Authentication 2003 √ ∙ ∙ ∙Cross-Enterprise User Assertion 2006 √ ∙ ∙ ∙Basic Patient Privacy Consents 2006 ∙ √Personnel White Pages 2004 √ √ ∙Healthcare Provider Directory 2010 √ ∙ ∙Document Digital Signature 2005 √ √ √Document Encryption 2011 √ √ ∙November 25, 2011 59
    60. 60. ATNA Audit Trail and Node AuthenticationNovember 25, 2011 60
    61. 61. ATNA Profile Secure Node or Secure Application Access Controls  Functional – can be shown to enforce policies Audit Controls  SYSLOG + IHE/DICOM/RFC3881 Audit Message  Auditable Events Network Controls  Mutually Authenticated TLS  Or S/MIME or WS-Security or physical isolationNovember 25, 2011 61
    62. 62. ATNA: Actors / Transactions  ITI-1: Maintain Time Time Server Secure Node grouped with ITI-20: Record Audit Event Any IHE Actor  ITI-1: Maintain Time Secure Node grouped with Audit Repository PHI Application ITI-20: Record Audit Event ITI-19: Node Authentication  ITI-20: Record Audit Event Secure Node grouped with Any IHE ActorNovember 25, 2011 62
    63. 63. ATNA: Authenticate Node Transaction Mutually Authenticate all network communications of Sensitive Information Encrypt and Integrity Protect Standards  X.509 Digital Certificate  RSA Authentication  AES Encryption  SHA Integrity  Transport Layer Security (TLS) RFC 2246  Web-Services Security  S/MIMENovember 25, 2011 63
    64. 64. ATNA Authenticate Node Secured Node Dual Authenticated Links EHR System Physician Office ED Application XDS Secured Node Document Repository PACS XDS Document Registry XDS EHR System PACS Document Repository Provide & Register Docs Lab Info. System Teaching Hospital Community Clinic Secured Node Secured NodeNovember 25, 2011 64
    65. 65. Audit Log - Accountability Mitigation against unauthorized use  Investigate Audit log for patterns and behavior outside policy. Enforce policy  Secure Node requires appropriate Access Controls to enforce at the enterprise by XDS Source and Consumers Investigation of patient complaints  Investigate Audit log for specific evidence  ATNA Audit Repositories can filter and auto-forward Support an Accounting of Disclosures  ATNA Report is informed by XDS-Export + XDS-ImportNovember 25, 2011 65
    66. 66. Centralized Accountability HIE boundary EHR System PMS Physician Office ED Application XDS Document Repository XDS Document PACS Registry XDS Document Repository Query Document Register Document EHR System PACS Retrieve Document Provide & Register Docs Lab Info. Maintain Time System Maintain Teaching Hospital Maintain Time ATNA Audit Time record CT Time server Community Clinic repositoryNovember 25, 2011 66
    67. 67. Distributed Accountability Teaching Hospital State run HIE EHR System PMS Physician Office ED Application XDS Document Repository XDS Document PACS Registry XDS Document Repository Query Document Register Document EHR System PACS Retrieve Document Provide & Register Docs Lab Info. Maintain Time System ATNA Audit Maintain record Maintain Time repository ATNA Audit Time record CT Time server Community Clinic repository ATNA Audit record HIE boundary repositoryNovember 25, 2011 67
    68. 68. Example: Audit Log Cascade Sjfldjlsdj a Kdjldsj Clinic A Lsjldjl EMR jfjfjlslkjln Lslasdjj;ask;sls Sflksdjfl;saf Salasaska Faslskf;sf Slsjlsdjlsdjf Lsjflsdjldsjfs Audit HIE Infrastructure Slkfjsdlfjldsf lsjfldsjfldsfj Sjfldjlsdj a Lslasdjj;ask;sls Faslskf;sf lsjfldsjfldsfj 1) Many audit events, both internal Audit and external 2) Local Audit Repository Service filters out events correlating to HIE interactions 3) HIE Audit Record combines with others for total HIE viewNovember 25, 2011 68
    69. 69. ATNA: References Status: Final Text IHE ITI Technical Framework  Vol. 1 - Section 9  Vol. 2a - Sections 3.19, 3.20 “Security Considerations” section found in other Profiles may specialize how ATNA is applied The Audit Event Message typically specialized in Vol 2 at the Transaction level  PIX QueryTransaction : See section Vol 2a:  XDS Register Document Set-b: See section Vol 2b: 25, 2011 69
    70. 70. XUA Cross-Enterprise User AssertionNovember 25, 2011 70
    71. 71. What Problem is Being Solved? XUA Problem Statement: The industry needs a standards-based method to provide the initiating user‟s identity in cross-enterprise transactions in a way that the responder can make access decisions and proper audit entries.November 25, 2011 71
    72. 72. Value Proposition Extend User Identity across organizations  Users include Providers, Patients, Clerical, etc  Must supports cross-enterprise transactions (e.g XDS, XCA), can be used inside enterprise  Distributed or Centralized Identity management (Directories) Provide information necessary so that receiving actors can make Access Control decisions  Authentication mechanism used  Attributes about the user (roles)  Does not include Access Control mechanism Provide information necessary so that receiving actors can produce detailed and accurate Security Audit TrailNovember 25, 2011 72
    73. 73. Technical Solution Initial scope to XDS.b Stored Query and Retrieve  Relies on Web-Services  Easily extended to any Web-Services transactions  Leverage WS-I Basic Security Profile 1.1 Use SAML 2.0 Identity Assertions  Does not constrain „how‟ the Assertion was obtained  Supporting Kantara Initiative (formerly Liberty Alliance)  May be obtained using WS-Trust or SAML Define grouping behavior with EUA and ATNANovember 25, 2011 73
    74. 74. XUA: Attribute Extension supplement User Role  To support Role Based Access Control Consent / Authorization  To support use-cases where the requesting party has explicit consent Purpose Of Use  Carry an indicator of what the reason for the transaction is and what will be done with the resultNovember 25, 2011 74
    75. 75. XUA encoded in Web-Services TLS - HTTP HTTP Who is Authority? SOAP Envelope SOAP Header How/Why to Trust? WS-Security Security Constraints (time)? SAML 2.0 Assertion Assertion Authentication Who is User? Statement How they were Attribute Statement authenticated? Authorization Decision What Roles apply? Statement What is the Purpose? Assertion SecurityTokenReference Signature Original Transaction Security Signature SOAP Header What Consent Security Token SOAP Body applies? Reference Original Transaction SOAP Body SOAP BodyNovember 25, 2011 75
    76. 76. Level of Identity Assurance Multi-Factor Token PKI/ Digital Signature Increased $ Cost Knowledge-Based Kerberos Very High Username - Password High PIN/User ID Medium Low Access to Access to Verification Remote Summary of Local Of Data Clinical Clinical research EHR/EMR Transcription Entry Increased Need for Identity AssuranceNovember 25, 2011 76
    77. 77. XUA ActorsNovember 25, 2011 77
    78. 78. Implementation Example EHR(ATNA Secure Node) XDS Registry (ATNA Secure Node) XDS Consumer Patient Data X-Service User Audit user auth X-Identity provider Provider XUA = Web-Services Security + SAML Assertions User Key: Audit Log Auth Original Transaction XUA Assertion TLS ProtectionsNovember 25, 2011 78
    79. 79. XUA: References Status: Final Text IHE ITI Technical Framework  Vol 1: Section 13  Vol 2b: Section 3.40 Standards Used  SAML 2.0 Identity Assertions  Web-Services Security header  WS-I Basic Security ProfileNovember 25, 2011 79
    80. 80. BPPC Basic Patient Privacy ConsentNovember 25, 2011 80
    81. 81. Problem In a cross-enterprise or cross-community environment how are the Privacy Preferences of the Patient (Consumer) made known and thus enforced? Consent is given and retracted Consent in some environments is only for a specific time There may be many consents relevant to different organizations or situations Need to support Privacy Policies beyond consent, such as authorizing research accessThe BPPC Solution is only BASIC, advanced consents not supportedNovember 25, 2011 81
    82. 82. How does it work? (1 of 3)A Patient Privacy Policy Domain (e.g. XDS AffinityDomain) Develop “Patient Privacy Policies”,  E.g. Opt-In, Opt-Out-fully, Opt-Out-Safe, No-Publish Assign each “Patient Privacy Policy” a Privacy Domain wide unique identifier – “Patient Privacy Policy Identifier” Configure Access Control engines to recognize these “Patient Privacy Policies” with the rules necessary to enforce them Define the default rule that is used when no consent is found for a given PatientNovember 25, 2011 82
    83. 83. How does it work? (2 of 3)Capture a Patient consent Inform the patient about the available “Patient Privacy Policies” that they can chose from (Acknowledge) A “Patient Privacy Policy Acknowledgement Document” is created identifying that the patient has agreed to the policy or policies (a type of CDA document)  May include a scanned image – such as a scan of the patient ink-on- paper signature on a replica printed version of the same policy  May be digitally signed – such as by the clerk witnessing the consent  May be time-limited The “Patient Privacy Policy Acknowledgement Document” is made available using same mechanism as is used for clinical documents in that Privacy Domain (e.g., XDS)  eventCodeList – holds the “Patient Privacy Policy Identifiers”November 25, 2011 83
    84. 84. How does it work? (3 of 3)Access Controls enforce consent Assumes Access Control is implemented with sufficient ability to enforce any Patient Privacy Policy allowed by the Patient Privacy Domain Can Leverage any interoperability profile in use: ATNA, EUA, XUA, PWP and metadata (e.g. confidentialityCode) Can Leverage application functionality such as Break-Glass XDS Query on Patient ID for BPPC type documents  If zero results returned – use default rule  Else for each result returned validate entry startTime and stopTime (to eliminate expired consents)  Use configured logic for remaining using eventCodeList as the list of acknowledged “Patient Privacy Policy Identifiers”November 25, 2011 84
    85. 85. Standards and Profiles Used Key Properties  Support Human Readable Consents  Support Machine Processable Access Controls  Support for standards-based Role-Based Access Control Standards  CDA Release 2.0  XDS Scanned Documents  Document Digital Signature  Cross Enterprise Document Sharing (XDS, XDR, and XDM)  Cross Community Access (XCA)November 25, 2011 85
    86. 86. Enforcing BPPC OPT-OUT at the HIE Hospital Domain HIE Domain EHR 6) Return Query Results Integrated XDS Document Registry Document Consumer Document Repository Access Control 1) Authenticates User Management Identity and Access Management 4) Looks in Document Registry for any BPPC documents If OPT-OUT found  Return 3) Intercepts Transaction zero results and inspects XUA and XDS Query parametersNovember 25, 2011 86
    87. 87. BPPC Enables Basic Opt-In or Basic Opt-Out Specific cases  authorize a specific use Control Use or Publication  Existence of Opt-Out could forbid publication  Typically Normal data is always published and control is on use of the data Time based Consent  Episodic Consent Site specific ConsentNovember 25, 2011 87
    88. 88. BPPC: References Status: Final Text IHE ITI Technical Framework  Vol 1: Section 19  Vol 3: Section 5.1  Options added to other transactions • Vol 2a: Section 3.18 • Vol 2b: Section 3.32, 3.41, 3.42, 3.43November 25, 2011 88
    89. 89. ATNA + EUA + XUA + BPPC Access Controls leveraging the Security ProfilesNovember 25, 2011 89
    90. 90. Access Control model mapped to IHE Security and Privacy Profiles XDS …November 25, 2011 90
    91. 91. Role-Based-Access-Control mapped to confidentialityCodes for OPT-IN  Normal Sharing Billing Information Sensitive Clinical General Clinical Administrative Sensitivity Mediated by Direct Care Information Information Information Information Research ProviderFunctional Role HL7 confidentialityCode (2.16.840.1.113883.5.25) L N D R V TAdministrative Staff X XDietary Staff XGeneral Care Provider X XDirect Care Provider X X X XEmergency Care Provider (e.g. EMT) XResearcher XPatient or Legal Representative X X X XNovember 25, 2011 91
    92. 92. Role-Based-Access-Control mapped to confidentialityCodes for OPT-OUT Only Direct Care Billing Information Sensitive Clinical General Clinical Administrative Sensitivity Mediated by Direct Care Information Information Information Information Research ProviderFunctional Role HL7 confidentialityCode (2.16.840.1.113883.5.25) L N D R V TAdministrative StaffDietary StaffGeneral Care ProviderDirect Care Provider X Break Glass Permission XEmergency Care Provider (e.g. EMT)ResearcherPatient or Legal Representative X X X XNovember 25, 2011 92
    93. 93. Distributed Access Control – enabled by XUA XDS Document XDS Registry ATNA ConsumerAccess Control XDS Document XDS Registry ATNA + XUA Consumer Access Control XDS Document XDS Registry ATNA + XUA ConsumerAccess Access Control ControlNovember 25, 2011 93
    94. 94. Supported Security Mis-Use-Cases Prevent Indiscriminate attacks  Mutual Auth TLS Patient asks for Accounting of Disclosures  informed by ATNA log Protect against malicious neighbor doctor  informed by ATNA log Patient that retracts consent to publish  Repository is local, manual Provider Privacy  User identity is not exposed Malicious Data Mining  queries are all patient based Access to Emergency data set  BPPC policy VIP  XDR/M, BPPC (Local enforcement) Domestic violence victim  BPPC policy (Local enforcement) Daughter with sensitive tests  XDR/M BPPC policy Sensitive topics  Don‟t publish, BPPC policy Legal Guardian (cooperative)  BPPC policy (Local enforcement) Care Giver (assists w/ care)  BPPC policy (Local enforcement)November 25, 2011 94
    95. 95. Profiles mapped to Security & Privacy Controls Audit Log Authentication Identification and Control Data Access Secrecy Data Integrity Non-Repudiation Patient Privacy Security & Privacy Controls ProfileIHE Profile IssuedAudit Trails and Node Authentication 2004 √ √ √ √ √ √ √Consistent Time 2003 √ ∙ √Enterprise User Authentication 2003 √ ∙ ∙ ∙Cross-Enterprise User Assertion 2006 √ ∙ ∙ ∙Basic Patient Privacy Consents 2006 ∙ √Personnel White Pages 2004 √ √ ∙Healthcare Provider Directory 2010 √ ∙ ∙Document Digital Signature 2005 √ √ √Document Encryption (in development) 2011 √ √ ∙November 25, 2011 95
    96. 96. Conclusion IHE provides the Interoperability Profiles needed to enable Security and Privacy  Much of Security and Privacy is policy, operational environment, procedures, and functional capabilities of systems As standards develop and mature new profiles will be created Continuous Risk Assessment is necessary at all levels  Profile writing (Cookbook for Security Considerations)  System design and implementation  Network design  Physical layout  Organizational  Privacy/Security Domain  CommunityNovember 25, 2011 96
    97. 97. Healthcare Provider Directory (HPD)November 25, 2011 97
    98. 98. HPD IntroductionHPD supports queries against, and management of, healthcareprovider information that may be publicly shared in a directorystructure. HPD directory structure is a listing of the following twocategories of healthcare providers that are classified by providertype, specialties, credentials, demographics and servicelocations.  Individual Provider: A person who provides healthcare services, such as a physician, nurse, or pharmacist.  Organizational Provider: Organization that provides or supports healthcare services, such as a hospital, Healthcare Information Exchange (HIE), Managed Care, Integrated Delivery Network (IDN), and Association.
    99. 99. What Problem is Being Solved? HPD Problem Statement: The industry needs a standards-based method to support queries against, and management of, healthcare provider information that may be publicly shared in a directory structure.
    100. 100. HPD ScopeDesigned to maintain a structured list ofattributes for both organizations (such asclinics) and people (such as physicians)Allows extensibilityLeverages ISO standard (21091)Designed to enable cross organizationaldirectory access
    101. 101. HPD Value PropositionSingle Authoritative Knowledge Base Reduce duplicate and unconnected user info database Single place to update • Name Changes • New Phone Number • Additional AddressesEnhance Workflow and Communications Providing information necessary to make connections • Phone Number • Email Address • Postal AddressCommon data model supports semantic interoperabilityContributes to Identity Management Additional methods of identity cross verification • Name, address, phone number, email • Cross reference with Enterprise User Authentication identity Can contain certificates
    102. 102. HPD Selected Use CasesYellow pages lookupQuery providers and their associations for SocialServices Disability DeterminationEmergency Responders Identification in planning foran emergency eventProvider Authorization and lookup during anemergency eventForwarding of Referral Documents to a SpecialistCertificate RetrievalLanguage Retrieval
    103. 103. HPD Actor Diagram Provider Information FeedProvider Information [ITI-59] Provider Information Source Directory Provider Information Query [ITI-58] Provider Information Consumer
    104. 104. HPD ActorsThree Actors Provider Information Directory – Processes queries to search for providers based on criteria received from the Provider Information Consumer actor and processes management operations based on actions received from the Provider Information Source actor. Provider Information Consumer – Initiates query requests. Provider Information Source – Initiates management commands consisting of Add, Update, or Delete requests.
    105. 105. HPD Transactions & OptionsTwo Transactions Provider Information Query [ITI-58] – Sends query commands. Provider Information Feed [ITI-59] – Sends management commands.One Option Provider Information Feed – Used to specify when the optional Provider Information Feed transaction is supported by the Provider Information Directory.
    106. 106. HPD Relationships
    107. 107. HPD Process Flow
    108. 108. HPD Organizational Provider
    109. 109. HPD Individual Provider
    110. 110. HPD Security and PrivacySecurity and privacy for HPD is established via othermechanisms ATNA can optionally be used for node authentication and secure audit logging EUA to authenticate users XUA for access control PWP for system users identification IT best practices LDAP authentication for attribute protectionRegional-specific legal, regulatory, policy, privacy,and security analysis is suggestedSee the HPD supplement section 28.4 for a securityconsiderations analysis
    111. 111. HPD References Status: Trial Implementation IHE IT Infrastructure Technical Framework Supplement Healthcare Provider Directory (HPD) – Primary Content Standards Used  LDAP  DSML  ISO/TS 21091November 25, 2011 111
    112. 112. DSUBDocument Metadata Subscription supplement
    113. 113. DSUB Overview The Document Metadata Subscription (DSUB) supplement contains two related parts: Publish/Subscribe Infrastructure: General framework for defining web-services based publish/subscribe interactions Document Metadata Subscription (DSUB) Integration Profile: Use of subscriptions within an XDS Affinity Domain or across communities113
    114. 114. Publish/Subscribe Infrastructure Presents a framework for building event- driven information exchange patterns using a publish/subscribe data exchange model Defines the transport of publish, subscribe and notify messages. Supports IHE profiles which define the use case specific content to be carried in the publish, subscribe and notify messages  Document Metadata Subscription (DSUB)114 first profile to use this framework.
    115. 115. Publish/Subscribe Infrastructure Actors and Transactions Publisher Publish Notification Subscribe Subscriber Broker Notify Notification Recipient115
    116. 116. Possible Combined Actors Publisher Publisher Notification Subscribe Subscriber Publish Broker Notify Notification Subscribe Broker Notification Publisher Recipient Notify Notification Subscribe Broker Notification Subscriber Recipient Notify Notification Subscriber Recipient116
    117. 117. Document Metadata Subscription (DSUB) Integration Profile Defines a subscription which allows for the matching of metadata during the publication of a new document for a given patient, and results in the delivery of a notification. Enabled within an XDS Affinity Domain or XCA environment Use Cases  Emergency Department: Notification of new document availability during treatment  Primary Care Management: PCP receives notification when new documents for patient are available117
    118. 118. DSUB Actors and Transactions Document Metadata Document Metadata Publisher Subscriber Document Metadata Publish [ITI-54] Document Metadata Document Metadata Subscribe [ITI-52] Notification Broker Document Metadata Notify [ITI-53] Document Metadata Notification Recipient118
    119. 119. Transactions Document Metadata Subscribe : start a subscription for a particular topic and filtering within that topic. Supports full and minimal notifications and where to send the notification. Document Metadata Notify : send a notification about the availability of a document or documents of interest, based on the subscribers filters on selected topics Document Metadata Publish : notify that an event occurred for which there may be a subscription.119
    120. 120. DSUB Process Flow Notification Notification Publisher Subscriber Broker Recipient XDS Document XDS Document Source Subscribe ConsumerXDS Document Registry Publish Notify Publish Notify Unsubscribe Publish120
    121. 121. DSUB Subscription Topics and Standards DSUB Topic Tree  ihe:FullDocumentEntry : subscribes to Document Entry registration events; the notification shall contain the full metadata describing each matching Document Entry  ihe:MinimalDocumentEntry : subscribes to Document Entry registration events; the notification shall contain a minimal set of data (identifiers only) describing each matching Document Entry DSUB Standards  OASIS Web Services Notification Family of Standards • WS-BaseNotification 1.3 OASIS Standard • WS-BrokeredNotification 1.3 OASIS Standard • WS-Topics 1.3 OASIS Standard • ITI TF-2x: Appendix V  Filter expression • Registry Stored Query [ITI-18]121
    122. 122. DSUB References Primary  DSUB Supplement Rev 1.4 2010-08-10 Underlying Technical Framework Content  ITI TF-2a • Section 3.18 Registry Stored query  ITI TF-2b • Section Register Document Set-b Request • Section Message Semantics  ITI TF-2x • Appendix V “Web Services for IHE Transactions”122
    123. 123. Cross-enterprise Document Workflow (XDW)September, 2011 What IHE Delivers
    124. 124. XDW IntroductionThe Cross-Enterprise Document Workflow (XDW)profile enables participants in a multi-organizationalenvironment to manage and track the tasks relatedto patient-centric workflows as they coordinate theiractivities:  No central controller  No central scheduler  Decisions are made by the “edges” (providers, doctors, nurses, etc)  XDW coordinates these activities
    125. 125. XDW Problem StatementsNecessity: Digitizingclinical processes (paperless) and enhancing care coordination is a focus across organization and boundaries such as many regional and national projects Allexpect to manage workflows beyond a single organization:  Examples: eReferral & eOrders workflows
    126. 126. XDW FrameworkFramework: XDW is a framework operating in an XDS contest which support the management of clinical process XDW is a framework which need to be specialized and different Workflow Definition profiles will be write to define specific clinical process Increases the consistency of workflow interoperability, and enables the development of interoperable workflow management applications where workflow-specific customization is minimized Facilitates the integration of multi-organizational workflows with the variety of existing workflow management systems used within the participating organizations (peer-to-peer)
    127. 127. XDW Key Design ElementsKey XDW design elements: Provides a common, workflow-independent approach to interoperability Enables the support of a wide range a specific workflow “content” Designed to support the complexity of health services delivery with flexibility to adapt Provides the means to associate documents to a broad range of workflows Easy to deploy: no addt‟l centralized infrastructure . Scales to regions & nations. Builds upon the secured sharing of health documents provided by other IHE profiles (e.g. XDS, ATNA, BPPC, etc.)
    128. 128. XDW Framework Diagram
    129. 129. XDW Simple CaseWorkflow Document in XDW: Specified by XDW is generic across specific workflow content Manages workflow specific status with relationship to input/output documents Tracking the current/past steps of the workflow and engaged health care entities Workflow driven/enforced by the XDW actors, infrastructure provides transparency
    130. 130. Structure of the step in the XDW Workflow Document Structure of the Workflow DocumentWorkflow Document Structure: Workflow Document Information: documentID Overall workflow context title patient author/custodian Task level Information time: date/time/UTC workflow definition URN workflow ID Task describes an activity that is planned or workflow state (active/closed) has been accomplished. Attributes of the task: TaskList  Type Task 1 Date/time  Owner State Input  Current Status (created, in-progress, completed, Output etc.) Task Event history  References to documents used for input or produced as output Task ……..  The Task Event History tracks the past Task Events, up to the present state Task n Task Event history
    131. 131. Structure of the Workflow Document ! !It is possible divided the structure of "#!!the WD in 4 parts: 0**0-2"607"/ 0! ! "! # ! $%()*# & + , - . / 0 Part 1: elements derived from HL7 CDA - 1*"#012 "2 #0! "3+ 45standard + 318. 3805 #0! Part 2: two elements, patient and author, 2+ "2 0!defined in the XDWSchema with the !structure derived from HL7 R-MIM standard : 32 ! "012 ! "! # ! $%()*# & $% & () *+ , % -. / 012 & ! + , - 12 4 3 3 Part 3: elements defined by IHE XDW 3. 2 (! 9Profile ! , () *+ , ?1@31-0?#! 2 Part 4: the element <TaskList> in whichis defined by elements derived from the , () *+ , % -. / 012 0<. 01-0= . / >0(! ;OASIS WS-HumanTask standard. ! "! # ! $% & , () *+ , ; 2 . @ 32 ! 5! (6 578 $! 9/ : ; )*(6 "! , () *+ , % 0*"1"2 1A0*0(01-0! " ! ! "! # ! $%()*# & 73@ B"@! ) 2 <0=4 =2 ># ?$@ A =: + ?&
    132. 132. XDW Flow and Interactions in an XDS scenarioContent ContentCreator Consumer XDS 2. Consumers search Infrastructure about patient’s workflows 1. Sources post workflow document and referenced 3. Consumers retrieve document to the selected documents XDS Infrastructure from the XDS Content Infrastructure Updater 5. Consumers search Content about patient’sConsumer workflows 4. Sources update the workflow document and post possible new 6. Consumers retrieve referenced selected documents documents from the XDS Infrastructure
    133. 133. XDW Process Flow workflow definition 2- Admission of the patient 1-Visit and production of eReferral 3- Start of the Consultation The workflow within 5 – Possiblenotification to the GP 4 – End of the the organization is consultation and creation of the clinical encapsulated into a report single XDW step
    134. 134. XDW Process Flow first task of the process Workflow Document task: REQUESTED Status: COMPLETED Author: Mr.Rossi Time: date/time/utc Inputs: -> Lab Report Task A: Requested Outputs: Status 1: Completed -> eReferralDoc1 1-Visit and taskEventHistoryproduction of TaskEvent: 1 eReferral Status: COMPLETED Inputs: -> Lab Report Outputs: -> eReferralDoc1
    135. 135. XDW Process Flow second task of the process, first status Workflow Document REQUESTED task: REFERRED Status: INPROGRESS 2- Author: Mr.Brum Admission of Time: date/time/utc the patient Inputs: -> eReferralDoc1Task B: Referred Outputs: Status 1: In Progress -> taskEventHistory TaskEvent: 1 Status: The workflow INPROGRESS within the Inputs: organization is -> eReferralDoc1 encapsulated into Outputs: a single XDW step ->
    136. 136. XDW Process Flow second task of the process, second status Workflow Document REQUESTED task: REFERRED Status: COMPLETED Author: Mr.Brum Time: date/time/utc Inputs: Task B: Referred -> eReferralDoc1 Status 2: Completed Outputs: -> ClinicalRepDoc2 3- Start of the taskEventHistory Consultation TaskEvent: 1 TaskEvent: 2 Status: 5 – Possible The workflow COMPLETEDnotification to the 4 – End of the within the Inputs: GP consultation and organization is -> eReferralDoc1 creation of the clinical report encapsulated into Outputs: a single XDW step -> ClinicalRepDoc3
    137. 137. XDW profile and Workflow Definition profile  Cross Enterprise Document Workflow is:  a framework to manage workflows  a platform upon which a wide range of specific workflows can be defined with minimal specification and implementation efforts  workflow independent  applicable on different document sharing infrastructures  Workflow Definition Profile is:  the definition of a specific clinical process  a set of rules and task definition which characterize the process  the definition of the actors involved in the process and their roles