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.
Is there a plan to open INTEROPen data up beyond only being used for point of care use (for example, allowing a third party to access patient information for intelligent triage purposes)?
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.
How do we know the specifications for Transfers of Care (ToC) are ready without going and looking every day?
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.
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.
As a supplier it is a calculated risk engaging in development of emerging standards. How can we be certain that our development activities will result in products the NHS will want to buy?
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.
How will all the existing standards relate to new FHIR standards? Why won’t these be just another new standard like ITK or HL7 etc.?
I’m a supplier who wants to integrate with my commissioners (the NHS) – how do I engage them to take this forward?
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.
Given the length of time and money it took to implement PMIP and the lack of CAD adoption, how are you going to get FHIR adopted?
Are NHS England still requiring Trusts to achieve the October and December 2018 deadlines for ToC and Care Connect?
As the curation of the CareConnect profiles is done by the INTEROPen community, do you think there should be a review of locally flavoured CareConnect profiles (i.e. GP Connect) that have had business rules placed on them by the INTEROPen community, to ensure the core aim of the profile is still being achieved?
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.
Has the recently published KLAS report been reviewed by INTEROPen? Would the INTEROPen Interoperability Survey be a duplication of this?
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.