FAQs

INTEROPen doesn’t own or store any health-related content other than technical specifications and artifacts.

Tag: #Data

INTEROPen doesn’t have a tech stack as such. We communally define and publish standards for information exchange in and around the healthcare systems. Tech stacks are the remit of the IT system suppliers and local NHS organisations.

There are several ways in which you can keep informed of INTEROPen activities and news. Aside from following our updates on Twitter @INTEROPenAPI, by joining INTEROPen you will receive access to our online communication platform, Ryver. This is a space where INTEROPen members exchange news of developments, activities, and events, share ideas, and collaborate on projects such as our ongoing STU3 CareConnect Profile curation work.

We are currently in the process of making improvements to our website, where you will find news updates and have access to tools and resources, as well as community documents and all the documents which are discussed at the monthly INTEROPen Board meeting. As a member of INTEROPen, you will also receive a copy of our newsletter and news announcements via email.

To join INTEROPen, simply complete our joining form where you will be asked to read and agree to INTEROPen Terms and Conditions.

INTEROPen doesn’t own any data – it simply defines the standards for information exchange. However, the initial use cases have focussed on direct care. Where an appropriate use case exists it would be possible for a care provider to use the same specifications to access data for intelligent triage purposes. This decision lies with the local data controller.

Without wanting to sound too cliched, Interoperability is as much about the journey as the destination. Whilst it is easy to pull out a definition of Interoperability as being “the ability to exchange information between systems and for the receiving system to be able to process and reason on that data” we have to understand there are dependencies in getting there.

We need a standard information model that covers all the health and care data we want to exchange. FHIR is the first information model that will cover all the data but, as a global standard, it is currently incomplete and only a small part of it has been curated and localised, where necessary, for England.

IT Suppliers need to open up their systems to both generate and consume data based on the standard information model. Again, it is going to take time for IT Suppliers to achieve this as, once it is known what is required, it has to be planned into their roadmaps. In some cases, the contracts they are working to may have to be changed, which will also take time.

What INTEROPen is doing, in working with the NHS England CCIO, NHS England, the Service, Standard Bodies, and Suppliers, is prioritising the FHIR resources to curate and then implement. It will take time to curate even 95% of the data required, but the fact we have started with Transfers of Care and the Patient Summary for CareConnect APIs means we are addressing the most important data first.

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.

The Code4Health website states, “Code4Health provides a home for the increasing number of open source projects providing software suitable for use in health and care”. INTEROPen was set up as a community to help work with all interoperability stakeholders to create national open standards for interoperability. Naturally there is overlap in these areas and benefits of both initiatives. INTEROPen discussed a partnership with Peter Coates, NHS Digital Nominated Director of the Apperta foundation (“a prime supporter of Code4Health”) at the March 2018 INTEROPen board, minutes here, item 12.

We recognise the synergies between the too and have been in discussions about a more closely linked working partnership. Discussions continue.

No, membership is free

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.

The GDE’s, Fast Followers and LHCRE contracts stipulate the use of FHIR standards as does the NHS Standard Contract. This contractual and funded route covers approximately 60% of frontline NHS organisations.

 

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.

No, anyone can join and participate in INTEROPen discussions/activities.

INTEROPen is UK nation agnostic. As a growing action group, with funding provided as resource and support in kind, we have focused on where we can make a difference with the engagement we have. Initially, this was focused by working with NHS Digital and NHS England to build national CareConnect profiles to support GPConnect and Transfers of Care, whilst creating a basic set of National FHIR capabilities to support other care organisations and vendors who wish to develop interfaces for data exchange.

NHS Scotland and NHS Wales have recently shown interest in engaging with this work and discussing the profiles we are developing. Importantly, the many vendors in INTEROPen cover the 4 nations and, as implementers, play an important part in helping to ensure consistency in the design of the CareConnect specifications.

Tag: #Scope

FHIR is an HL7 standard and this initiative appears to have strong industry backing. Indeed, industry was the initial instigators of the decision to move to FHIR.

There is already a British Standards notice for SNOMED CT adoption by 2020. SNOMED is already being implemented in Primary Care and we are now looking at the rest of the estate.

Tag: #SNOMED

There are two parts to this: first of all, your primary engagement will always need to be with the NHS at a local level – these are your customers and your revenue stream. However, you may also wish to be able to advise your customers with regard to upcoming strategic moves around inter-organisational information exchange, especially with details of how your system(s) can help your customer meet the most recent contractual requirements for Transfer of Care and Open (CareConnect) APIs. I would recommend anyone in your position take an active roll in INTEROPen, where NHS England, NHS Digital, local CIO/CCIOs, other system suppliers, standards bodies etc. work together to develop and adopt open national standards for information exchange.

As a care provider, we would refer to you as a ‘customer’ because you purchase systems from your IT supplier/vendor. 

The Global Digital Exemplars (GDEs), Fast Followers and Local Health and Care Record Exemplar (LHCRE) contracts stipulate the use of FHIR standards as does the NHS Standard Contract. This contractual and funded route covers approximately 60% of frontline NHS organisations.

The two target dates are different but we are looking at Trusts to at least have plans in place to implement FHIR based Transfer of Care messages and Open (CareConnect) APIs.

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.

The use of the CareConnect standards we are working with should be covered by existing contracts that Suppliers are working within, together with their customers. Suppliers should, however, be reviewing these and if they believe they are subject to a CCN, should discuss that with their customers. Their customers may then want to discuss this with NHS England, as the current work being done is to satisfy the NHS Contract.

Both NHS Digital and PRSB are members of INTEROPen and have agreed to work collaboratively under the INTEROPen banner. The work by PRSB and NHS Digital is undertaken as members of INTEROPen under the framework of the INTEROPen end to end process towards achieving the unifying goal of all INTEROPen members.

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.

The KLAS report is essentially a report from a customers’ perspective on their supplier. The INTEROPen Supplier Survey is different; it is an opportunity for suppliers to go offer technical detail as to the capabilities of their products/services, focusing on progress towards the things that they need to develop and how can INTEROPen help. Results from the INTEROPen Supplier Survey will be triangulated with findings from other relevant surveys (including the KLAS report), to create a much more comprehensive and realistic representation of where suppliers are at, what needs to be done and where help is needed.