SNOMED & CTV3 response

[pacharanero]

The API response could contain a 'suggested' SNOMED (and CTV3?) code which would make it easier for implementers to store the data alongside a suitable clinical terminology code.

[pacharanero]

In discussion with one implementer, it was suggested that RCPCH should apply to SNOMED to add a code to the UK Edition for

"UK-WHO Height centile calculated using the RCPCH dGC API" (or something like that)

This is because interoperability between systems is still rather limited as regards structured data - a numeric value passed between systems, with a highly specific code such as the above would always preserve its meaning.

Whereas a numeric value and a less specific code such as "248338008 | Height centile (observable entity)", perhaps with additional structured data about the API used for the result (eg "RCPCH Digital Growth Charts, UK-WHO"), would be less likely to be preserved across system transfers because the structured data is less consistently handled between different systems.

IF we did apply to UKTC for our own suite of SNOMED codes, we would have to consider whether we would need to include a version number in the text (rubric) portion.

[BB-1313]

Kudos for getting the recognition! However isn't that against the original goal of having the data (height) stored by the system and applying the API as required for centiles instead of hard coding it which is the problem with SNOMED CT? Basil

…

On Mon, 5 Jul 2021, 12:43 Marcus Baw, ***@***.***> wrote: In discussion with one implementer, it was suggested that RCPCH should apply to SNOMED to add a code to the UK Edition for "Height centile calculated using the RCPCH dGC API" (or something like that) This is because interoperability between systems is still rather limited - a numeric value passed between systems, with a highly specific code such as the above would always preserve its meaning. Whereas a numeric value and a less specific code such as "248338008 | Height centile (observable entity)" with additional structured data about the API used for the result, would be less likely to be preserved across system transfers. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARV7QENF2CBQQSFCG5HTGRTTWGLHNANCNFSM4ZJHQEYA> .

[pacharanero]

Thanks @BB-1313 - however I think you may be combining a few different issues there.

1. Saving data locally - Our aim is that the systems (eg your hospital EPR) will record the measurement (eg height) and then consult the API to get the height centile. But the expectation from us it that they will save the returned centile/SDS/advice-string values locally. If they didn't do this then they would need to hit the API for every historical measurement (could be dozens) every time the chart is viewed. We don't persist ANY data in the API, so it is up to the implementer to persist everything.

2. SNOMED-CT choice of code - in many GP systems and (one would hope) other types of clinical system, a numerical value can be stored alongside a SNOMED term, almost as a key:value pair. This means that a SNOMED code like "1273921732 | UK-WHO Height centile calculated using the RCPCH dGC API" paired with a numeric like 70, would be quite resistant to being rendered meaningless by subsequent data migrations (eg between GP systems). That key:value pairing is likely to be quite stable across GP2GP transfers and other migrations, and is represented similarly in both systems. (The alternative is to use a more complex data structure to hold information about what API was used - ie the "RCPCH" and "UK-WHO" parts would not be in the SNOMED term but in a structured data object. However, this data object is likely to be differently implemented in different systems, and it is easy for the metadata ("RCPCH" and "UK-WHO") to get somehow separated from the 70.)

[BB-1313]

No I understand that, I just wonder why you need to store the processed data with it's own classification code when it could simply be generated as required from the raw height value. I guess that's answered by your first point it would swap local storage of processed values for repeated need to process raw data. I know there are also potential issues about who made what interpretation based on what information at a point in the past but there are other ways to potentially handle this documentary problem without an ever expanding set of codes. I guess that would be a whole different architecture that doesn't fit the status quo as easily. Sort of touches on what we were chatting about a while back though.

…

On Mon, 5 Jul 2021, 14:05 Marcus Baw, ***@***.***> wrote: Thanks @BB-1313 <https://github.com/BB-1313> - however I think you may be combining a few different issues there. 1. *Saving data locally* - Our aim is that the systems (eg your hospital EPR) will record the measurement (eg height) and then consult the API to get the height centile. But the expectation from us it that they will *save* the returned centile/SDS/advice-string values locally. If they didn't do this then they would need to hit the API for every historical measurement (could be dozens) every time the chart is viewed. We don't persist ANY data in the API, so it is up to the implementer to persist everything. 2. *SNOMED-CT choice of code* - in many GP systems and (one would hope) other types of clinical system, a numerical value can be stored alongside a SNOMED term, almost as a key:value pair. This means that a SNOMED code like "1273921732 | UK-WHO Height centile calculated using the RCPCH dGC API" paired with a numeric like 70, would be quite resistant to being rendered meaningless by subsequent data migrations (eg between GP systems). That key:value pairing is likely to be quite stable across GP2GP transfers and other migrations, and is represented similarly in both systems. (The alternative is to use a more complex data structure to hold information about what API was used - ie the "RCPCH" and "UK-WHO" parts would not be in the SNOMED term but in a structured data object. However, this data object is likely to be differently implemented in different systems, and it is easy for the metadata ("RCPCH" and "UK-WHO") to get somehow separated from the 70.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#140 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ARV7QEKWWRUJA4SQJAPWVX3TWGUYJANCNFSM4ZJHQEYA> .

[dc2007git]

Is this still of importance @pacharanero ?