Transfers of Care (1)

We have a Transfer of Care website where you can join our mailing list and receive updates regarding the Transfer of Care initiative, including updates regarding the final specification.

The Programme is currently creating the remaining Transfer of Care profiles and these will be complete and published on the FHIR reference server mid-May 2018. The next iteration of the message specifications is due to be published on GitHub early June 2018 for Inpatient, Mental Health and Emergency Care discharge summaries and the end of June 2018 for Outpatient Letters. We will, however, make every effort to offer more coordinated communications going forward.

Did you find this FAQ helpful?
0
0

Standards Development (4)

GPConnect profiles and key national profiles should all be reviewed by the INTEROPen community, as it is essential for vendors who are implementing them on a national scale to influence the design and ensure there is consistency. However, because the Level 2 CareConnect profiles and CareConnect APIs have a basic set of constraints and operations to support UK interoperability, we hope that they can be taken and used by many local areas, vendors and innovative projects to develop new models of care in a way that doesn’t hold back innovation. We expect these projects will share their learning and specifications, and as they develop and scale, we envisage certain rules and patterns and other profiles emerging that may need to be plugged into a curation process so that other regions can pick them up with a degree of confidence that their design has been technically and clinically validated. Some regions may specifically come to INTEROPen for curation first, as they wish to gain further guidance. We will need to support both approaches.

Did you find this FAQ helpful?
0
0

The GP Connect API is the nationally supported mechanism to access GP information. CareConnect APIs are the nationally supported mechanism to develop interoperable exchange interfaces for other use cases; GDEs and LHCREs will implement these as OPEN APIs. The intention is for vendors to align their interoperability interfaces to these specifications so that we can move away from proprietary standards to open ones. All www.INTEROPen.org vendors have signed up to this principle.

The GP Connect API will allow vendors to query GP systems for patients’ summary GP information, as defined by the API. There are different phases to the API implementation; the first includes access to the summary information where the content is uncoded, i.e. HTML only. Another phase will return structured and coded information in FHIR, including content such as medications and allergies. Under GPSoC contractual agreements, GP suppliers must support the GP Connect API, providing a mechanism for relevant third-party systems to access patients’ GP information where needed.

The FHIR profiles used in GP Connect are derived from, or ‘Children’ of, the National CareConnect FHIR profiles, and therefore consistent with them clinically and technically. ‘Child’ profiles are referred to as Level 3 CareConnect profiles or Use Case specific profiles. The National CareConnect profiles are Level 2, or ‘Parent’ profiles. Guide to Level 2 and Level 3 profiles: https://drive.google.com/file/d/1k4ITq_Qdzw-jak_x4RCiGDZ57ZgRxUIG/view

These Level 2 and Level 3 CareConnect profiles have all been ‘curated’ by INTEROPen to be UK-specific localisations of the International STU3 core resources. It is accepted that there may be different versions of the CareConnect profiles (and therefore GPConnect ones) over time to accommodate changes, amendments, new requirements. Guide to curation: https://docs.google.com/document/d/1IbSdRTdWg-ZsbYmkkYZSGV1PVtxNmf7jkx7LneXYa0w/edit?usp=sharing

A basic set of CareConnect APIs also now exists, including a reference implementation: https://nhsconnect.github.io/CareConnectAPI/. These CareConnect APIs use the Level 2 FHIR CareConnect profiles. NHS England and NHS Digital are requiring GDEs and LHCREs to support these for their interoperability needs. INTEROPen plans to work with GDEs and LHCREs to help refine and develop these CareConnect APIs as the exchange use cases become developed.

It should be noted that, at present, the functional scope of GP Connect & CareConnect are not the same. GP Connect includes APIs for Appointment Booking and updating records, which Care Connect does not.

Did you find this FAQ helpful?
0
0

The FHIR profiles created by INTEROPen members reflect UK standards. However, it is important to understand the curation process used is there to only extend the profiles where necessary to fit local requirements. The curation process takes the FHIR STU3 resource definitions from HL7 International and reviews them to understand where they need to be changed to reflect NHS requirements in England.

This curation process includes not only the NHS but suppliers too, and it is in suppliers’ interests to keep them as close to the international version as possible.

Did you find this FAQ helpful?
0
0

Priority profiles are already under discussion by various groups within INTEROPen/NHS England/NHS Digital/ PRSB/TechUK and the CCIO/CIO Networks. INTEROPen is acting as a community where these priorities can be defined together.

Did you find this FAQ helpful?
0
0

Care Connect (4)

GPConnect profiles and key national profiles should all be reviewed by the INTEROPen community, as it is essential for vendors who are implementing them on a national scale to influence the design and ensure there is consistency. However, because the Level 2 CareConnect profiles and CareConnect APIs have a basic set of constraints and operations to support UK interoperability, we hope that they can be taken and used by many local areas, vendors and innovative projects to develop new models of care in a way that doesn’t hold back innovation. We expect these projects will share their learning and specifications, and as they develop and scale, we envisage certain rules and patterns and other profiles emerging that may need to be plugged into a curation process so that other regions can pick them up with a degree of confidence that their design has been technically and clinically validated. Some regions may specifically come to INTEROPen for curation first, as they wish to gain further guidance. We will need to support both approaches.

Did you find this FAQ helpful?
0
0

The GP Connect API is the nationally supported mechanism to access GP information. CareConnect APIs are the nationally supported mechanism to develop interoperable exchange interfaces for other use cases; GDEs and LHCREs will implement these as OPEN APIs. The intention is for vendors to align their interoperability interfaces to these specifications so that we can move away from proprietary standards to open ones. All www.INTEROPen.org vendors have signed up to this principle.

The GP Connect API will allow vendors to query GP systems for patients’ summary GP information, as defined by the API. There are different phases to the API implementation; the first includes access to the summary information where the content is uncoded, i.e. HTML only. Another phase will return structured and coded information in FHIR, including content such as medications and allergies. Under GPSoC contractual agreements, GP suppliers must support the GP Connect API, providing a mechanism for relevant third-party systems to access patients’ GP information where needed.

The FHIR profiles used in GP Connect are derived from, or ‘Children’ of, the National CareConnect FHIR profiles, and therefore consistent with them clinically and technically. ‘Child’ profiles are referred to as Level 3 CareConnect profiles or Use Case specific profiles. The National CareConnect profiles are Level 2, or ‘Parent’ profiles. Guide to Level 2 and Level 3 profiles: https://drive.google.com/file/d/1k4ITq_Qdzw-jak_x4RCiGDZ57ZgRxUIG/view

These Level 2 and Level 3 CareConnect profiles have all been ‘curated’ by INTEROPen to be UK-specific localisations of the International STU3 core resources. It is accepted that there may be different versions of the CareConnect profiles (and therefore GPConnect ones) over time to accommodate changes, amendments, new requirements. Guide to curation: https://docs.google.com/document/d/1IbSdRTdWg-ZsbYmkkYZSGV1PVtxNmf7jkx7LneXYa0w/edit?usp=sharing

A basic set of CareConnect APIs also now exists, including a reference implementation: https://nhsconnect.github.io/CareConnectAPI/. These CareConnect APIs use the Level 2 FHIR CareConnect profiles. NHS England and NHS Digital are requiring GDEs and LHCREs to support these for their interoperability needs. INTEROPen plans to work with GDEs and LHCREs to help refine and develop these CareConnect APIs as the exchange use cases become developed.

It should be noted that, at present, the functional scope of GP Connect & CareConnect are not the same. GP Connect includes APIs for Appointment Booking and updating records, which Care Connect does not.

Did you find this FAQ helpful?
0
0

The FHIR profiles created by INTEROPen members reflect UK standards. However, it is important to understand the curation process used is there to only extend the profiles where necessary to fit local requirements. The curation process takes the FHIR STU3 resource definitions from HL7 International and reviews them to understand where they need to be changed to reflect NHS requirements in England.

This curation process includes not only the NHS but suppliers too, and it is in suppliers’ interests to keep them as close to the international version as possible.

Did you find this FAQ helpful?
0
0

Priority profiles are already under discussion by various groups within INTEROPen/NHS England/NHS Digital/ PRSB/TechUK and the CCIO/CIO Networks. INTEROPen is acting as a community where these priorities can be defined together.

Did you find this FAQ helpful?
0
0

FHIR (3)

GPConnect profiles and key national profiles should all be reviewed by the INTEROPen community, as it is essential for vendors who are implementing them on a national scale to influence the design and ensure there is consistency. However, because the Level 2 CareConnect profiles and CareConnect APIs have a basic set of constraints and operations to support UK interoperability, we hope that they can be taken and used by many local areas, vendors and innovative projects to develop new models of care in a way that doesn’t hold back innovation. We expect these projects will share their learning and specifications, and as they develop and scale, we envisage certain rules and patterns and other profiles emerging that may need to be plugged into a curation process so that other regions can pick them up with a degree of confidence that their design has been technically and clinically validated. Some regions may specifically come to INTEROPen for curation first, as they wish to gain further guidance. We will need to support both approaches.

Did you find this FAQ helpful?
0
0

The FHIR profiles created by INTEROPen members reflect UK standards. However, it is important to understand the curation process used is there to only extend the profiles where necessary to fit local requirements. The curation process takes the FHIR STU3 resource definitions from HL7 International and reviews them to understand where they need to be changed to reflect NHS requirements in England.

This curation process includes not only the NHS but suppliers too, and it is in suppliers’ interests to keep them as close to the international version as possible.

Did you find this FAQ helpful?
0
0

Priority profiles are already under discussion by various groups within INTEROPen/NHS England/NHS Digital/ PRSB/TechUK and the CCIO/CIO Networks. INTEROPen is acting as a community where these priorities can be defined together.

Did you find this FAQ helpful?
0
0

Communications (1)

We have a Transfer of Care website where you can join our mailing list and receive updates regarding the Transfer of Care initiative, including updates regarding the final specification.

The Programme is currently creating the remaining Transfer of Care profiles and these will be complete and published on the FHIR reference server mid-May 2018. The next iteration of the message specifications is due to be published on GitHub early June 2018 for Inpatient, Mental Health and Emergency Care discharge summaries and the end of June 2018 for Outpatient Letters. We will, however, make every effort to offer more coordinated communications going forward.

Did you find this FAQ helpful?
0
0

Load More