FHIR format for the API response

[pacharanero]

FHIR ('Fast Healthcare Interoperability Resources', pronounced 'Fire') is a standard interchange format for medical data. It has been suggested that the response from the Growth Chart API should be in the form of a FHIR Resource.

More information on FHIR can be found here: https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources

The FHIR specifications are here: http://hl7.org/fhir/

At present the data returned by the API is in a structured data format called JSON (JavaScript Object Notation) and this is also the most common way that FHIR resources are transmitted. From initial discussions between myself and @eatyourpeas we think it is likely that we would be able to return a FHIR Resource as the API response.

[pacharanero]

Looking through the FHIR spec, I think the most appropriate resource for us to use for calculated centile data would be Observation

The CodeableConcept we would use to identify the type of measurement should be expressed in SNOMED-CT (not FHIR's default LOINC - we don't use LOINC in the UK) and there are number of suitable options within the descendants of this concept Body measure (observable entity)

[statist7]

I strongly endorse the use of the FHIR format. Neil Sebire who leads the electronic patient data initiative at Great Ormond Street requires all APIs to access patient data via FHIR.

[clarotech]

If you need any help with the FHIR aspects of this - then happy to assist.

[pacharanero]

Thanks @clarotech! Does the approach outlined above seem reasonable?

We're going to have two API endpoints, both will present exactly the same calculations, but the FHIR endpoint will wrap the response in an appropriate FHIR resource. If you have any thoughts regarding this approach, or the choice of resource etc then we'd be pleased to chat

[pacharanero]

I had a chat with some UK GP IT experts with a lot of experience in SNOMED terminology, regarding the correct coding entities to use. They agreed that the below are the correct SNOMED concepts.

248356008 |Weight centile (observable entity)|
248338008 |Height centile (observable entity)|
446974000 |Body mass index centile (observable entity)|
248397001 |Head circumference centile (observable entity)|

I'm going to propose the following as a rough idea of the JSON structure to be added to the 'simple' API response.

{
  "suggested_clinical_terminologies": [
    {
      "snomed-ct": {
        "concept_id": "248397001",
        "term_text": "Head circumference centile (observable entity)"
      }
    },
    {
      "readv2": {
        "code": "649Z.",
        "term_text": "Child HC centiles NOS"
      }
    }
  ]
}

We should support SNOMED-CT, which is what is currently used in GP systems in England, and possibly consider other terminologies such as Read Version 2, which is still in active use in Scotland, where EMIS PCS is used.

Using this kind of structure we make the terminology component extensible so that other coding systems (eg international) can be added in the future.

[eatyourpeas]

What about SDS and advice strings?

[pacharanero]

We can add them as needed, you can look for suitable terms here:

SNOMED-CT https://termbrowser.nhs.uk/?perspective=full&conceptId1=446974000&edition=uk-edition&release=v20201028&server=https://termbrowser.nhs.uk/sct-browser-api/snomed&langRefset=999001261000000100,999000691000001104

ReadV2 https://hscic.kahootz.com/connect.ti/t_c_home/view?objectId=407588

[pacharanero]

Another JSON format for this would be to use FHIR's CodeableConcept verbatim (even though the simple API won't return FHIR (there will be another endpoint for FHIR)

"valueCodeableConcept": {
	"coding": [
			{
				"system": "http://snomed.info/sct",
				"code": "248397001",
				"display": "Head circumference centile (observable entity)"
			}, {
				"system": "https://acme.lab/resultcodes",
				"code": "649Z.",
				"display": "Child HC centiles NOS"
			}
		],
		"text": "Head circumference centile"
	}

[pacharanero]

I am pausing work on this until the changes to Term References and Gestation Age Correction are all stable

[KevinMayfield]

Do you mean putting a FHIR API inside your app?

I'm not sure that has much use. I would see sourcing data from external sources via FHIR as more useful. I.e. you source data from external EPR/EHR (they have FHIR API's) and or get feeds of data from these or PHR apps.
That I feel would be a better use of FHIR.

[KevinMayfield]

Are you wanting to expose the calculation API for other vendors to use? (Then yes FHIR would be appropriate)

[pacharanero]

Do you mean putting a FHIR API inside your app?

No, we don't need to do that.

Are you wanting to expose the calculation API for other vendors to use? (Then yes FHIR would be appropriate)

Yes, the idea is that vendors can use this API to get clinically validated, warranted growth calculations instead of having to implement the centiles, SDS and other calculations themselves. The implementation is HUGELY complex and not a simple lookup table.