How can FHIR APIs accelerate innovation in health IT? Let\u2019s take a closer look<\/strong><\/h5>\n\n\n\nHaving standardised interfaces between systems (whether real-time REST, more complex Operations, or even derivative standards like SMART or CDS-Hooks) along with a standardised way of representing that data (i.e. the resources) will allow vendors and providers to focus on creating applications that meet real business needs, rather than on the necessary infrastructure to support secure exchange. There is promising development underway and this was worked on at the recent FHIR Connectathon at the HL7 Working Group Meeting<\/em> in New Orleans.<\/p>\n\n\n\nThe actual track worked on was Consumer Centred Data Exchange<\/em>, and we were exploring ways that the consumer can control who has access to their data\u2013and for what purpose. Consumers may be happy to share all their data with their care deliverer, but only a subset of that data (perhaps excluding mental health data) with a researcher.<\/p>\n\n\n\nAs you can imagine, this can be very complex as there are a numerous moving parts involved, these can include:<\/p>\n\n\n\n
\n- A way of expressing their preferences \u2013 and a place to store them.<\/li>\n\n\n\n
- Being able to \u2018tag\u2019 or \u2018categorise\u2019 data so that the sharing rules can be applied.<\/li>\n\n\n\n
- An identification system for the participants \u2013 consumers, providers, organisations, roles and more e.g. a Provider Directory.<\/li>\n\n\n\n
- Engines that can apply these rules when delivering data to a recipient.<\/li>\n<\/ul>\n\n\n\n
Below is a diagram of the components that we put together at the Connectathon. It\u2019s important to appreciate that, for most of the components, there was more than one vendor and\/or organisation that had a system that we tested. In fact, seven organisations and vendors were part of this track.<\/p>\n\n\n\n![\"\"](\"https:\/\/orionhealth.weareiceberg.co\/wp-content\/uploads\/2019\/05\/ecosystem-thinking-based-on-fhir-apis_fhir-ecosystem-1440x1018.png\")
<\/figure>\n\n\n\nLooking at the components we had:<\/p>\n\n\n\n
\n- A Consent service, that held the consumers sharing preferences as a FHIR Consent resource.<\/li>\n\n\n\n
- We used a terminology service to tag the data items with the agreed tags \u2013 such as sensitivity or \u2018type\u2019 (e.g. Mental health, Drug use).<\/li>\n\n\n\n
- There was an EHR that stored the data. In our case, there was a single EHR \u2013 but there is no reason why there couldn\u2019t be more.<\/li>\n\n\n\n
- A \u2018privacy engine\u2019 that applies the consent rules.<\/li>\n\n\n\n
- An audit server that recorded access.<\/li>\n\n\n\n
- A couple of applications that consumed the data \u2013 both provider and consumer.<\/li>\n<\/ul>\n\n\n\n
It\u2019s important to appreciate that all the interfaces between systems were based on FHIR (and derivatives)\u2013or at least we were working towards that goal. This means that we can effectively swap out individual implementations to use a different provider, as long as they supported the interface.<\/p>\n\n\n\n
What we were able to demonstrate was that a consumer could create a Consent resource and save that on the Consent service. Then the applications could operate with different users and roles (e.g. Provider or Researcher) for different organisations and would receive a different set of data based on their role and the patient\u2019s Consent.<\/p>\n\n\n\n
There is a way to go before this is all working as smoothly as we need, but it\u2019s a great example of using ecosystem thinking and demonstrates how multiple vendors and organisations can work together to support that thinking.<\/p>\n\n\n\n
Read my white paper, where we will look at how FHIR and several derived standards could underpin such an ecosystem, and the types of services or components that will be needed.
<\/p>\n\n\n\n
The actual track worked on was Consumer Centred Data Exchange<\/em>, and we were exploring ways that the consumer can control who has access to their data\u2013and for what purpose. Consumers may be happy to share all their data with their care deliverer, but only a subset of that data (perhaps excluding mental health data) with a researcher.<\/p>\n\n\n\n As you can imagine, this can be very complex as there are a numerous moving parts involved, these can include:<\/p>\n\n\n\n Below is a diagram of the components that we put together at the Connectathon. It\u2019s important to appreciate that, for most of the components, there was more than one vendor and\/or organisation that had a system that we tested. In fact, seven organisations and vendors were part of this track.<\/p>\n\n\n\n Looking at the components we had:<\/p>\n\n\n\n It\u2019s important to appreciate that all the interfaces between systems were based on FHIR (and derivatives)\u2013or at least we were working towards that goal. This means that we can effectively swap out individual implementations to use a different provider, as long as they supported the interface.<\/p>\n\n\n\n What we were able to demonstrate was that a consumer could create a Consent resource and save that on the Consent service. Then the applications could operate with different users and roles (e.g. Provider or Researcher) for different organisations and would receive a different set of data based on their role and the patient\u2019s Consent.<\/p>\n\n\n\n There is a way to go before this is all working as smoothly as we need, but it\u2019s a great example of using ecosystem thinking and demonstrates how multiple vendors and organisations can work together to support that thinking.<\/p>\n\n\n\n Read my white paper, where we will look at how FHIR and several derived standards could underpin such an ecosystem, and the types of services or components that will be needed.\n
<\/figure>\n\n\n\n\n
<\/p>\n\n\n\n