From Epic:

Comment

What's the definition for MS?

Proposal

Define MustSupport.

Consider acting as Document Responder in Find Document References and Retrieve Document transactions from IHE MHD

Final versions of the IG will be published as static content to a permanent location.

A separate static HTML page will hold an index of versions of the IG.

IHE have drafted a QEDm standard: https://wiki.ihe.net/index.php/Query_for_Existing_Data_for_Mobile_(QEDm) that defines a FHIR API for retrieval of patient information very similar to those that were identified during the discovery phase. Should we reference or align to this standard?

In addition, NHS Digital have a Clinical Data Sharing API under active development as part of UK Core [
https://simplifier.net/guide/uk-qepd?version=current] that was last updated in November 2022. @KevinMayfield: Is there a spec for international QEPD? Is this an 'official' NHS Digital project? How does it fit in with the prioritisation of work by the UK FHIR Board?

Consider acting as a Clinical Data Source in the Mobile Query Existing Data transaction from IHE QEDm as discussed in #4

Implementation guide should be published to standard repositories so that it is available to others.

Two options for publishing:

• HL7 Tooling
• Simplifier

Need to consider whether implementers who wish to derive product-specific capability statement are able to do this without using Simplifier.

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/clinical_data.html#allergyintolerance-search

This feedback applies across many (most?) of the UK Core profiles.

Comment

Overall, you should not mandate support of individual query parameters unless there's clearcut value for them.

Proposal

Rather, you should mandate search parameter combinations. For example, AllergyIntolerance?clinical-status is mandated, but AllergyIntolerance?patient&clinical-status is only recommended. The second search, combining patient and clinical-status is so much more useful than the first.

For an example of nuanced search parameter requirements, see IPA's Observation: https://hl7.org/fhir/uv/ipa/CapabilityStatement-ipa-server.html#Observation1-8

i.e. search-type Patient interaction

Should we provide guidance around use of national identifiers (NHS Number, CHI Number etc)?
How strongly should this guidance be enforced?
Should the guidance be provided via implementation guidance OR via conformance resources (is this even possible?)?

Subject to consultation with NHS Scotland and Strategic Planning and Performance Group of the Department of Health, HL7 UK will allocate systems for national identifiers used in Scotland and Northern Ireland that can be used within this IG.

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/index.html#actors

Comment

Why is a "Patient Index Provider" a distinct actor?

Proposal

Please add some sentences explaining why this distinction is specifically important in the UK.

More of a question.

Noticed

"meta" : { "profile" : [ "https://fhir.hl7.org.uk/StructureDefinition/UKCore-Patient", "https://fhir.hl7.org.uk/ukcore-access/StructureDefinition/UKCoreAccessPatientIndexPatient" ] },

This was routine behaviour in STU3 but is it necessary in R4? If this is included in examples then developers will duplicate.
My view is it's down the server to state what profile conformance it accepts and those profiles should be in the conformance statement. It's not necessary to include in resources.

Should it be included in examples??

Agree time for regular meeting

From Epic:

Asset

<<UK-CORE-ACCESS_Clinical_Data_Provider_Cap_Statement.pdf>>
<<UK-CORE-ACCESS_Patient_Index_Provider_Cap_Statement.pdf>>

Comment

Search parameters - they seem to be differently defined in the capability statement

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/related_specifications.html

Comment

It would probably be best to link to IPA's 1.0 publication instead of build … unless you're planning on doing so as part of your own publication.

Proposal

Link to IPA's 1.0 publication instead of build

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/consumer.html

Comment

Why is Patient.Search relevant for the Consumer case? I wouldn't expect you'd ever want to give consumers much functional access to Patient.search.

Where does UK Core Access deviate from IPA? And why?

Proposal

Add significant clarification around the authorization and data access expectations when using Patient.search in a Consumer context.

Please consider publishing the comparison results between UK Core and IPA as an addendum to the IG.

From Epic:

Comment

Are simple read interactions excluded from the specification? Only Search is specified in the CapabilityStatement, and only search is discussed (for example in the description of error handling), which is unreasonable

From Epic:

Asset

<<UK-CORE-ACCESS_Clinical_Data_Provider_Cap_Statement.pdf>>
<<UK-CORE-ACCESS_Patient_Index_Provider_Cap_Statement.pdf>>

Comment

Need to define client capability statement. The current text about "Consumer" doesn't seem very clear. Also see above comment about including IPA's take on SMART

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/clinical_data.html#medicationdispense-search

Comment

Similar to the comments on MedicationAdministration, what is the use case of MedicationDispense? Is it for getting data for logisitical reasons or patient clinical care?

FHIR supports the concept of chained searches. These could be used to search based on a business identifier such as a national number or a PAS number.

For example: GET [base]/MedicationStatement?patient.identifier=https://fhir.nhs.uk/Id/nhs-number|9912003888

This would be a courtesy method for consumers but may be more complex for providers to implement. As the same outcome can be achieved using 2 searches, this will not be included within MVP.

i.e. capabilities interaction

Patient search by demographics for future consideration.

Consider acting as a Patient Demographics Supplier in the Patient Demographics Query interaction from IHE PDQm.

Agree scope for MVP

Which of these questions are in scope?

Who is requesting information? e.g. Dr X, Practitioner at NHS Trust | Dr Scott, parent of Janette
Who is the request about? e.g. Ms Janette Scott, NHS Number 4123456789
What endpoints are available? e.g. https://trust.nhs.uk/fhir
Can the endpoint provide information for a specific patient?
What types of information can the endpoint provide? e.g. Condition, MedicationStatement, Procedure
What information of each type does the endpoint hold for a specific patient?

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/patient_index.html#patient-birthdate

Comment

Why is support for partial date searching, operators and multiple parameters important? Especially as you are mandating it across the board, at the data type level, rather than by known prioritized use-cases?

Proposal

Don't mandate things without needing them.

What tooling do we use for profile definition?

Propose:
https://build.fhir.org/ig/HL7/fhir-shorthand/
https://github.com/FHIR/sushi

From Epic:

Asset

https://simplifier.net/guide/uk-core-implementation-guide/Home/ProfilesandExtensions/ExtensionLibrary/ExtensionUKCore-BirthSex?version=1.0.0

Comment

Why is this a required extension?

Proposal

Prefer if this was optional for now as not sure if this is captured

Develop high level plan to seek feedback from UK interoperability community on this draft

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/consumer.html

Comment

What are the expectations for authentication/authorization for consumer apps?

Note that IPA includes specific parts of SMART in order to provide a comprehensive capability for consumer apps to access patient data.

Proposal

Consider replacing this page with SMART requirements, a la: https://hl7.org/fhir/uv/ipa/access.html#gaining-access-to-a-patient-record

At present the repository includes the snapshot definition of UKCore-Patient so that it can be referenced from UKCoreAccessPatientIndexPatient.

Ideally, this IG would reference definitions directly from the UKCore package so that we can guarantee to be using the correct version.

To reproduce the problem, remove input/resources/UKCore-Patient.json so that the build process uses the public repositories to pull the snapshot and then execute $ npm run compile. Sushi reports an error: Structure Definition https://fhir.hl7.org.uk/StructureDefinition/UKCore-Patient is missing a snapshot. Snapshot is required for import. File: /Users/Dunmail/Documents/Development/UK-Core-Access/input/fsh/profiles/PatientIndexPatient.fsh

HL7 Tooling will be used to publish the IG (#6).

A CI pipeline will be configured to do this automatically when changes are committed to this repository

From Epic:

Asset

<<UK-CORE-ACCESS_Clinical_Data_Provider_Cap_Statement.pdf>>
<<UK-CORE-ACCESS_Patient_Index_Provider_Cap_Statement.pdf>>

Comment

Should use capabilities and actors (extensions for defining better "must support" conditions

From Epic:

Asset

https://simplifier.net/guide/uk-core-implementation-guide/Home/ProfilesandExtensions/ExtensionLibrary/ExtensionUKCore-Evidence?version=1.0.0

Comment

Guidance says this is an optional extension, but it has been coded as a 1..1

Proposal

Change to 0..1

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/clinical_data.html#medicationadministration-search

Comment

What is the use case of MedicationAdministration search? This resource has very limited adoption and its maturity level is only 2. It relies heavily on how reliably the data is captured in the source system, how the consumer interpret the data, and how aligned the source and consuming systems are. The worry is that it won't necessarily provide the wholistic view of a patient's medication intake.

From Epic:

Asset

<<UK-CORE-ACCESS_Clinical_Data_Provider_Cap_Statement.pdf>>
<<UK-CORE-ACCESS_Patient_Index_Provider_Cap_Statement.pdf>>

Comment

should use "complies with" extension to show relationship to IPA

Derive parameters and parameter combinations from International Patient Access: https://build.fhir.org/ig/HL7/fhir-ipa/CapabilityStatement-ipa-client.html#Patient1-9 so that common searches used to find patients are available

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/clinical_data.html#medicationadministration-search

Comment

What is the use case for a standalone MedAdministration search on only status or effective-time?

Proposal

Remove the requirement that the server shall support returning all MedAdministations with the same status, or with the same effective-time. Rather, appropriate combinations of these search parameters should be required.

From Epic:

Asset

<<UK-CORE-ACCESS_Clinical_Data_Provider_Cap_Statement.pdf>>
<<UK-CORE-ACCESS_Patient_Index_Provider_Cap_Statement.pdf>>

Comment

Need to confirm the text description of capabilities is properly reflected in the capability statements

From Epic:

Asset

https://build.fhir.org/ig/HL7-UK/UK-Core-Access/patient_index.html#patient-family

Comment

The more discrete search parameters provided, the more accurate the search and the less likely an app (and it's user) is to confuse two patients.

The requirement/recommendation to support the following standalone search parameters have significant performance costs with limited utility and some risk: family, given, gender, name, birthdate.

Proposal

Please consider mandating groupings of Patient search parameters, not individual demographic parameters. E.g. Given, family, and birthdate