1. 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

2. 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

3. 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.

4. 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

5. 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

6. PDLS Integration Profile (3/3)
PDLS Actor Diagram

7. 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.

8. PDLS Supplement Open Issues

9. 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'.

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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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.

17. 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) .

18. 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)

19. 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.

20. 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.

21. 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

22. QEDm Supplement Open Issues

23. 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.

24. 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 (g)(7) and Application Access – Data Category Request (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

25. 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

26. 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

27. 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:
• status – as a value from {current, entered in error}
Search parameters:
Current Resource Lists:
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
Argonaut Data Query Implementation Guide Server:
Argonaut Data Query Implemenation Guide Client:

28. 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: (in general each Provenance object can link N ‘target’ Resources to M ‘entity’ Documents)
To consider the available FHIR specifications on FHIR & XDS Documents specifically the DocumentReference FHIR resource:
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

29. 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:

30. 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

31. QEDm: details Query specs from QED
Referring QED supplement – section
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

32. 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

33. Suggested CPs for existing Profiles

34. 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 ?