Charles Parisot, GE Healthcare Fabio Buti, Dedalus IHE ITI & PCC Supplements Patient-centric Data-element Location Service (PDLS) Query for Existing Data for mobile (QEDm) Wednesday, February 8, 2017 Charles Parisot, GE Healthcare Fabio Buti, Dedalus

PDLS Integration Profile (1/3) The Patient-centric Data-element Location Service (PDLS) profile introduces: A “fine grained data element” access to health data That coexists and complements the coarse grained access (document as a coherent set of fined grained data elements). Currently IHE provide a complete set of profiles for a coarse grained access (XDS/XCA/MHD) and offers, for fine grained access, the QED (Query for Existing Data) profile based on the HL7V3 standard, but: HL7V3 is too complex for this task and does not meet the constraints of mobile platforms. Newer FHIR standard is a much better suited technology  a new QEDm (QED for mobile) profile based on it is needed

PDLS Integration Profile (2/3) Health information sharing relies on different granularity of exchanges: • Document-Level Granularity: optimum to ensure that contained data has clarity of context in care delivery and reflects source attestation (responsibility) of clinical data shared. • Data Element-Level Granularity: optimum when list of Data Elements relevant to a “time span” or a set of encounters are of interest (e.g.: the list of allergies at the time of medication dispensation, or information reconciliation at the time of hospital admission). Both granularity levels deliver different benefits and their efficient coexistence is the objective of this profile.

Problems & Allergies Professional Services PDLS environment and multilevel granularity access to health information Hospital Specialist Emergency Department Laboratory GP Doc CDA CDA DOCUMENTS: Consultation Note Laboratory Report Discharge Summary … PATIENT Doc CDA Doc CDA Data Location Service DATA ELEMENT: Vital Signs Diagnostic Results Problems & Allergies Professional Services Immunizations Medications Doc CDA Doc CDA

Fine Grained Resources Use Cases – Combined Document (whole and restful) access and Data Element Access Introduce a source option “document provenance option” in base QEDm ? What are the other types of “provenance” that QEDm should include ? It is allowed in PDLS to have data-elements not coming from documents (impact on privacy) Share Discharge Summary or Transfer of Care Document Registry & Repository Fine Grained Resources Provide &Register Docs Source of Document Query for Specific Data Elements Query & Retrieve Docs Query for Specific Data Elements within a document Use a provenance selection option in QEDm Consumer of Document Consumer of Fine Grained Data Consumer of Fine Grained Data Consumer of Fine Grained Data Access Discharge Summary Access Medication List or Transfer of Care Doc Access Allergy List

PDLS Integration Profile (3/3) PDLS Actor Diagram

QEDm Integration Profile The Query for Existing Data for Mobile (QEDm) profile supports lightweight dynamic queries for clinical data elements including vital signs, problems, medications, immunizations, diagnostic results, procedures, visit history etc... The profile is functionally equivalent to QED Profile, but conceived to be implemented by application specific to mobile devices. The solution is based on a standardized query interface to health (HTTP-based RESTful APIs) and the resulting transaction can be used to query&retrieve a list of specific data elements, persisted as FHIR resources.

PDLS Supplement Open Issues

PDLS Supplement: Open Issue #1 (1/8) Open Issue: fine grained data 'Location’ and Reconciliation in an Affinity Domain with N Repositories: We are defining a data locator service that allows to collect all the fine-grained information of interest by querying in a 'central point'. Case #1: 1 XDS Registry + 1 XDS Repository (& FHIR Repository) the Clinical Data Source can be providing data-elements resources as the central point for querying & retrieving ALL fine-grained data Reconciliation may be placed at this central point.  OK (for centralized reconciliation & access) Case #2: 1 XDS Registry + N XDS Repository (Each with a Clinical data Source or FHIR Repository) The unique XDS Registry still works well as master top-level index for coarse grained XDS Documents, but there is no longer have a central point to query/access fine-grained information. Where should the Clinical Data Source & Reconciliation Agent be conveniently placed to work ? If the Clinical Data Source Actor is grouped with each Doc Repository Actor, N Document Repositories, each provides a subset of the data The Clinical Data Source just like the Reconciliation Agent are no longer unique. Is that an issue ? Reconciliation when necessary may be better to happen in one pass, when all information is gathered by the 'collector/source', just before being provided to the 'consumer'.

PDLS Supplement: Open Issue #1 (2/8) PDLS Potential Deployment Models

Fine Grained Resources Deployment A – Combined Document (whole and restful) access and Data Element Access (3/8) Simple Share Discharge Summary or Transfer of Care Document Registry & Singular Repository Fine Grained Resources Provide &Register Docs Source of Document Query for Specific Data Elements Query & Retrieve Docs Consumer of Document Consumer of Fine Grained Data Consumer of Fine Grained Data Access Discharge Summary Access Medication List or Transfer of Care Doc Access Allergy List

Fine Grained Resources Deployment B – Combined Document (whole and restful) access and Data Element Access (4/8) Clear Fine Grained Resources (central agregator) on the fly (easy privacy) or central data server ? Document Registry Share Discharge Summary or Transfer of Care Document Repository Document Repository Provide & Register Docs Source of Document Query & Retrieve Docs Query for Specific Data Elements Query for Specific Data Elements within a document Consumer of Document Consumer of Fine Grained Data Consumer of Fine Grained Data Access Discharge Summary Access Medication List or Transfer of Care Doc Access Allergy List

Fine Grained Resources (Recon) Fine Grained Resources Deployment C – Combined Document (whole and restful) access and Data Element Access (5/8) Clear Document Registry Share Discharge Summary or Transfer of Care Document Repository Fine Grained Resources (Recon) Document Repository Fine Grained Resources (Recon) Provide & Register Docs Source of Document Query & Retrieve Docs Query for Specific Data Elements Query for Specific Data Elements within a document (Recon) Consumer of Document (Recon) Consumer of Fine Grained Data Consumer of Fine Grained Data Access Discharge Summary Access Medication List or Transfer of Care Doc Access Allergy List

Fine Grained Resources Fine Grained Resources Fine Grained Resources Deployment D – Combined Document (whole and restful) access and Data Element Access (6/8) Fine Grained Resources Proxy (on the fly) Challenging (because of synchronous transactions only in REST and harder recon, on-demand docs may require) Document Registry Share Discharge Summary or Transfer of Care Document Repository Fine Grained Resources Document Repository Fine Grained Resources Provide & Register Docs Source of Document Query for Specific Data Elements Query & Retrieve Docs Query for Specific Data Elements within a document Consumer of Document Consumer of Fine Grained Data Consumer of Fine Grained Data Access Discharge Summary Access Medication List or Transfer of Care Doc Access Allergy List

Access Discharge Summary Access Medication List Deployment E – Combined Document (whole and restful) access and Data Element Access (7/8) Fine Grained Resources (Central data) + Recon Document Registry Push Share Discharge Summary or Transfer of Care Document Repository Push Fine Grained Resource Sources Document Repository Fine Grained Resources Sources Provide & Register Docs Source of Document Query & Retrieve Docs Query for Specific Data Elements Query for Specific Data Elements within a document Consumer of Document Consumer of Fine Grained Data Consumer of Fine Grained Data Access Discharge Summary Access Medication List or Transfer of Care Doc Access Allergy List

PDLS Supplement: Open Issue #1 (8/8) CONCLUSION: When multiple Doc Repositories in an affinity domain deployment, 5 deployment models previously introduced have been identified. Pros and cons of each deployment model choice will be discussed in an informative Appendix.

PDLS Supplement: Open Issue #2 Open Issue: Is fine-grained content always derived/derivable from Documents ? PREFACE: PDLS assumes that the shred repository/registry is being fed by document sources with documents that are shared. The data elements contained in these documents is offered for data-element level query and extracted as a clinical data source actor and delivered as query responses to clinical data consumers. Is this the only input that is used ? QUESTIONS: Couldn’t we consider fined grand data elements that have not be created/shared through the provide and register of documents ? This was already considered in the on-demand documents option of XDS. Another way to ask the same question, is whether the PDLS Profile should be limited to consider fine-grained content derived/derivable from Documents that are persisted in a certain XDS Repository? CONCLUSION: It is allowed in PDLS to have data-elements not coming from documents. Impacts of such flexibility will be analyzed (e.g. impact on privacy) .

PDLS Supplement: Open Issue #3 Open Issue: Privacy and BPPC consent policies Any specification about privacy? CONCLUSION: It’s necessary to provide some “guidance”, but no need for a solution as this would be the topic of the grouping og existing privacy IHE profiles or another profile (future). The grouping with existing profiles may be of interest. Possible solutions: To apply the existing BPPC/APPC consent from the source document to each “fine-grained” element (privacy properties inheritance). This is a simple and effective way to enure consistent policies for both document-level and data-element level access. For data elements not coming from documents we could consider a new BPPC/APPC consent for specifying if someone can query or not for a certain category of information (e.g. consent to access the Vital Signs)

PDLS Supplement: Open Issue #4 Open Issue: integrity and credibility of information accessed The profile provides a controlled approach to provide the same health information either in a document level coarse grain level granularity or in a data-element granularity. The relationship between these two levels results in a number of situations that could result in “defects in information integrity and/or credibility in the information being accessed. The following points should be discussed in the profile: Different forms of mappings may have to be performed (it is beyond the scope of the PDLS Profile to specify such mapping between data elements in documents and data elements accessed directly. Such mappings may not be perfect (typical limitations in semantic mappings). Some information contained in the documents may not be “expressed” as data-elements (e.g.textual elements) and be “lost” in the data-element queries vs the documents Some sources that have “signed” a document may object that it be “taking apart in data-elements” out of the document context. These would not visible on the data-element granularity. Include examples: non-coded information is critical to interpret the coded information, constraint on use-display only, a treatment-stress induced that results non-generic vital signs-context is key). PDLS is designed to “limit” thee above issues, by offering the means to avoid these weaknesses of the “data-element granularity”, by allowing the user that gets a query lists to easily request the document(s) that are sources of that data-element of interest. Conclusion: It’s necessary to provide a good discussion on the above issues and “guidance” on the profile to help implementers of the profile.

PDLS Supplement: Open Issue #5 (1/2) Open Issue: Check/add the key requirements for consistency to ensure that health data are consistently exchanged at different level of granularity. The following points of consistency seem to be most important: When a Data Element is accessed by a Clinical Data Consumer Actor and found relevant, one need to offer a simple way to extract: identifiers from the Data Element in order to access one or more Documents in which this item was initially shared. identifiers from the Document where the Data Element was found relevant to access “related” items that may have been shared. When relevant Documents are queried and a list of matching Documents is returned, rather than retrieving the set of Documents, one may want to access the content of these documents by type of content Some of those ‘identifiers” may also be needed for clinical decision traceability. The following points needs particular attention: Conclusion: PDLS shall precisely define the identifiers that grant consistency between Documents and/or Data Elements (e.g: from Data Element  discover the Document from which the resource is extracted.

Approach to PDLS Data Location PDLS profile takes an approach where data location is aligned with the document repositories that would support both document based retrieval and data-element query, thus making locating documents and data elements considered jointly. The starting point may be: to use the document query as locator for documents, and from this coarse grain location, that seem to have some efficiency advantages, consider three routes: move to the retrieve of specific documents (and access their fine-grained content), aggregation through on-demand documents aggregation through selection of lists of fine-grained data elements Access to a set of document contents through retrieve data-element queries

QEDm Supplement Open Issues

QEDm: classification of Clinical Data (1/3) Classification from QED QED Category  Description Common Observations These are a collection of simple measurements or reported values that can be determined using simple measuring devices (e.g., Height, Weight), or which can be reported by the patient (date of last menstrual period). These measurements do NOT include anything that might be recorded as a problem, allergy, risk, or which requires interpretation, clinical decision making, or diagnostic quality equipment or procedures for performing the measurement. Diagnostic Results These are a collection of observations made or performed using laboratory testing equipment, imaging procedures, vision examinations, et cetera. Problems and Allergies These are a collection of diagnoses, clinical findings, allergies, or other risk factors that are recorded for the patient. The information may be obtained from patient reports, or through clinical decision making. It includes such information as would be found in social and family history sections of clinical reports. This classification can be further subdivided into three groups. Conditions This is a collection of disease conditions for the patient. Intolerances This is a collection of the patient's allergies and other intolerances. Risk Factors This is a collection of the patients significant risk factors, as might be established based on a review of family history, social history, occupational exposures, et cetera. By themselves, they may not be indicative of a disease condition, but could contribute to one. Medications This is a collection of the medications that a patient is or has been taking for treatment of one or more conditions. Immunizations This is a collection of immunizations that have been given, or which are planned to be given to the patient. Professional Services This is a collection of procedures and/or encounters which the patient has participated in, or is expected to participate in.

QEDm: classification of Clinical Data (2/3) Classification from Argonauts The Argonaut data element query IGs are intended to meet the 2015 Edition certification criterion for Patient Selection 170.315(g)(7) and Application Access – Data Category Request 170.315(g)(8). They were created for each 2015 Edition Common Clinical Data Set. Where applicable they are based on the HL7 U.S. Data Access Framework (DAF) FHIR Implementation Guide. The Argonaut requirements per resource are a subset of those of the DAF IG (seen next slide). Requirements per Resource Type: Allergies Assessment and Plan of Treatment CareTeam Goals Immunizations Implantable Devices/UDI Laboratory Results Medications Patient Problems and Health Concerns Procedures Smoking Status Vital Signs

QEDm: classification of Clinical Data (3/3) Classification from US Core Implementation Guide (formerly DAF IG) Each profile defines the minimum mandatory elements, extensions and terminology requirements that MUST be present. A subset of these profiles are used by the [DAF-Research]. See also the specs on Clinical Summary Module. US Core Allergies Profile US Core Allergies Profile US Core CarePlan Profile US Core CarePlan Profile US Core CareTeam Profile US Core CareTeam Profile US Core Condition Profile US Core Condition Profile US Core Implanted Device Profile US Core Implanted Device Profile US Core Diagnostic Report Profile US Core Diagnostic Report Profile US Core Goal Profile US Core Goal Profile US Core Immunization Profile US Core Immunization Profile US Core Location Profile US Core Location Profile US Core Medication Profile US Core Medication Profile US Core Medication Request Profile US Core Medication Request Profile US Core Medication Statement Profile US Core Medication Statement Profile US Core Result Observation US Core Result Observation US Core Smoking Status Observation Profile US Core Smoking Status Observation Profile US Core Vital Signs Profile US Core Vital Signs Profile US Core Organization Profile US Core Organization Profile US Core Patient Profile US Core Patient Profile US Core Practitioner US Core Practitioner US Core Procedure Profile US Core Procedure Profile

QEDm Issue # 1: Requirements for QEDm vs QED Support listing of Pb, Med, Allergies, Med-Allergies 2 Supports listing of rest of DE (Data-element) per full QED List 3 Supports listing of additional DE per DAF resources 4 Supports access to DE across DAF defined resources 5 Identifies source documents from where DE was extracted, if any. 6 Selects source documents for scope of query 7 Flag in response that reconciliation has happen by clinical DE source 8 Shows specific DEs that have been reconciled

QEDm Issue #2: Scope Listing of Data Elements FHIR allows two approaches in specifying the QEDm query transaction and complementary reconciliation information (querying strategies in FHIR STU3): Querying ‘named’ Lists of resources (‘Operations’) Querying directly the underlying resources Available specifications for both different strategies: FHIR List Resource (STU3) $find operation - the following parameters SHALL be supported: • name – the coded name of the list to be retrieved, see: current defined list: http://build.fhir.org/lifecycle.html#current • status – as a value from {current, entered in error} Search parameters: http://hl7.org/fhir/2017Jan/list.html#search Current Resource Lists:http://build.fhir.org/lifecycle.html#current Argonaut Project specifications based on a subset of FHIR DAF Resource Profiles specifications: Argonaut Query Implementation Guide , currently still based on the HL7 U.S. Data Access Framework (DAF) FHIR DSTU2 Implementation Guide  Specific implementation profile for each Data Element resource (e.g.: Vital Signs http://www.fhir.org/guides/argonaut/r2/StructureDefinition-argo-vitalsigns.html) Argonaut Data Query Implementation Guide Server: http://www.fhir.org/guides/argonaut/r2/Conformance-server.html Argonaut Data Query Implemenation Guide Client: http://www.fhir.org/guides/argonaut/r2/Conformance-client.html

QEDm Issue #3: Identify Document Sources of Data Elements Consider the following: PCC-RECON: “When the Data Element comes from a Document, the ID of the document is used as the source. When the Data Element is the result of a query (such as QED), the query ID is the source. When the data comes directly from a system, provenance may not exist because there is not a document source ID from the system. The solution is to start broad and add the “provenance” Option (source of the data). …” The original Document(s) reference(s) is supported by the Provenance.entity: http://hl7.org/fhir/2017Jan/provenance.html (in general each Provenance object can link N ‘target’ Resources to M ‘entity’ Documents) To consider the available FHIR specifications on FHIR & XDS Documents https://www.hl7.org/FHIR/2017Jan/usecases.html#xds specifically the DocumentReference FHIR resource: https://www.hl7.org/FHIR/2017Jan/documentreference.html Query considerations: FHIR query on “resource” (e.g. medication), add “_reverse include” with “Provenance”. GET [base]/MedicationRequest?_revinclude=Provenance:target&criteria...Always on the GET by client and server must support. For list FHIR is an “operation” (not RESTfull GET). Is it worth exposing “list operations” because may be perfectly reconciled. Use Doc Resource versus and/or provenence resource

QEDm Issue #4: Manage reconciliation of Data Elements CONCLUSION: the reconciliation specific content is already defined by RECON existing [PCC-16] transaction (how to convey recon activities performed by the Reconciliation Agent when grouped with the Clinical Data Source). Currently the results of reconciliation are noted in the FHIR List resource. The requirements for this profile are defined in the following two sections: PCC Vol.3: 6.6.A - FHIR Reconciled List PCC Vol.3: 6.6.B - FHIR Provenance Constraints NOTES: RECON content specifications must be updated to FHIR STU3 See also considerations about multi-stage import/reconciliation supported by the Provenance Resource: http://hl7.org/fhir/2017Jan/provenance.html#6.2.4.6

QEDm Issue # 1: CONCLUSIONS Requirements for QEDm vs QED Support listing of Pb, Med, Allergies, Med-Allergies Yes 2 Supports listing of rest of DE (Data-element) per full QED List 3 Supports listing of addtl DE per DAF resources No ? 4 Supports access to DE across DAF defined resources Expected ? 5 Identifies source documents from where DE was extracted, if any. 6 Selects source documents for scope of query 7 Flag in response that reconciliation has happen by clinical DE source ? with RECON 8 Shows specific DEs that have been reconciled Yes, RECON

QEDm: details Query specs from QED Referring QED supplement – section 3.2.4.5 QED parameters from [PCC-2] A Clinical Data Consumer may supply parameters other than those required by this profile, but must appropriately handle any detected issue alert raised by the Clinical Data Source in its response. This <careProvisionCode> may be present. This element describes the information that is being looked for in the <value> element. When the <careProvisionCode> element is not present, it indicates that all relevant results are to be reported up to the maximum number specified in maximumHistoryStatements for each result. A Clinical Data Consumer can restrict the results returned in the query by setting the value attribute of <value> element in the <careProvisionCode> element to a code identifying the clinical data to be returned. A Clinical Data Source can use the codes specified in the sections below to obtain different kinds of clinical data. A Clinical Data Consumer implementing one of the options for that actor shall be able to issue a query using at least one of the codes listed for that option as specified in the table below. A Clinical Data Source implementing one of these options must support all codes listed in the table below for that option. Parameter Name Cardinality Clinical Data Consumer Clinical Data Source careProvisionCode 0..1 O R careProvisionReason 0..* careRecordTimePeriod clinicalStatementTimePeriod includeCarePlanAttachment maximumHistoryStatements patientAdministrativeGender patientBirthTime patientId 1..1 patientName Actor Option Code Returns Resource (Data Element) Vital Signs Option COBSCAT All Vital Signs Vital Signs Observation Any Code from the Vital Signs (…) The vital sign identified by the code Problems and Allergies Option MEDCCAT All problem entries Problem Entry CONDLIST All Concern Entries Concern Entry PROBLIST All Problem Concerns Problem Concern INTOLIST All Allergy Concerns Allergy and Intolerance Concern RISKLIST All Risks Diagnostic Results Option LABCAT All Lab Results Simple Observations DICAT All Imaging Results Medications Option RXCAT All Medications Medications MEDLIST CURMEDLIST All active medications DISCHMEDLIST Discharge Medications HISTMEDLIST All Historical Medications Immunizations Option IMMUCAT All Immunizations Immunizations Professional Services Option PSVCCAT All professional service entries Encounters Procedures Entry

QEDm: details DAF Resources into QED classification QED Category  Description FHIR resource Common Observations These are a collection of simple measurements or reported values that can be determined using simple measuring devices (e.g., Height, Weight), or which can be reported by the patient (date of last menstrual period). These measurements do NOT include anything that might be recorded as a problem, allergy, risk, or which requires interpretation, clinical decision making, or diagnostic quality equipment or procedures for performing the measurement. Argonauts: Vital Signs based on: DAF Vital Signs    Diagnostic Results These are a collection of observations made or performed using laboratory testing equipment, imaging procedures, vision examinations, et cetera. Argonauts: Laboratory Results based on : DAF Results  Problems and Allergies These are a collection of diagnoses, clinical findings, allergies, or other risk factors that are recorded for the patient. The information may be obtained from patient reports, or through clinical decision making. It includes such information as would be found in social and family history sections of clinical reports. This classification can be further subdivided into three groups. See the following three sub-categories Conditions This is a collection of disease conditions for the patient. Argonauts: Problems and Health Concerns based on: DAF-Condition (aka Problem) Intolerances This is a collection of the patient's allergies and other intolerances. Argonauts: Allergies based on: DAF AllergyIntolerance Risk Factors This is a collection of the patients significant risk factors, as might be established based on a review of family history, social history, occupational exposures, et cetera. By themselves, they may not be indicative of a disease condition, but could contribute to one. ?to consider? Smoking Status ?to consider? Observation Medications This is a collection of the medications that a patient is or has been taking for treatment of one or more conditions. Argonauts: Medication DAF Medication Statement DAF Medication Order ?to consider? DAF Medication Immunizations This is a collection of immunizations that have been given, or which are planned to be given to the patient. Argonauts: Immunizations DAF Immunization Professional Services This is a collection of procedures and/or encounters which the patient has participated in, or is expected to participate in. Argonauts: Procedures DAF Procedure ?to consider? DAF-Encounter

Suggested CPs for existing Profiles

Suggested SPs for existing PCC QED and RECON Profiles #1: align QED & RECON supplements to the current IHE supplement template Some collateral information could be removed, since already present elsewhere, to make all easier to understand #2: reorganize RECON profile, by considering the new QEDm profile (QEDm to be used in RECON as already done for QED) It seems that those are next step after QEDm has reached trial implementation. Is it OK to have them identified as open issues in QEDm to be handled by PCC Technical Committee ?