Stream: implementers
Topic: simplest Codeable Concept example
Erich Schulz (May 27 2016 at 08:37):
I am making a Flags table so need some Flag.code values...
Erich Schulz (May 27 2016 at 08:38):
is this legitimate as a simplest case:
code: {
text: 'Under care of APS',
coding: [{code: 'APS'}]
{
Erich Schulz (May 27 2016 at 08:59):
on reflection I guess I'm probably best, at this stage, simply storing the code - then doing a tranformation during any FHIR serve process...
Erich Schulz (May 27 2016 at 09:00):
i'm still working through the best way to use FHIR as the basis of an information model
Erich Schulz (May 27 2016 at 09:01):
i guess information model != interchange format
Lloyd McKenzie (May 27 2016 at 15:19):
You can send just text alone. No need to include a code. If you have a code, you really should have a system. Technically, the text element should come after coding, though JSON generally doesn't care
Robert McClure (May 27 2016 at 15:28):
+1 @Lloyd McKenzie The "should" there is a SHALL. @Erich Schulz PLEASE never make up codes. Codes are from CODE SYSTEMS that actually exist, follow rules, are published and maintained, and are available to others.
Lloyd McKenzie (May 27 2016 at 15:59):
We can't make it a SHALL because there are legacy environments that have codes and have no idea what system or namespace they come from.
Making up codes is fine - so long as you make up the code system they live in too. (And don't make up codes if there's a standard way to say what you need in a publicly available reliable code system)
Erich Schulz (May 27 2016 at 22:42):
If anyone can find me a code for "under care of APS" and "has received spinal morphine, not to receive parenteral opioids" I shall buy them a drink.
Erich Schulz (May 27 2016 at 22:48):
I understand the issues @Robert McClure, but local codes are every where. Mechanisms to manage that reality are critical. I am just making baby steps in my health service and need some runs on board so the case for migrating 50 legacy approaches towards Fhir based integration gets some serious consideration
Erich Schulz (May 27 2016 at 22:49):
An ontology engine is definitely on my radar but have to demonstrate ability to meet some clinical needs first
Grahame Grieve (May 27 2016 at 22:51):
APS = Australian psychological society?
Erich Schulz (May 27 2016 at 22:57):
"acute pain service"
Grahame Grieve (May 27 2016 at 23:01):
310072004: Acute pain service on the encounter, but I can't see where on the encounter clinical unit goes...
Erich Schulz (May 27 2016 at 23:05):
the flag is "under care of APS"
Erich Schulz (May 27 2016 at 23:06):
this applies between encounters and is a warning to the intern and a message to the ward nurses
Erich Schulz (May 27 2016 at 23:06):
"any pain issues contact us please"
Robert McClure (May 31 2016 at 20:38):
@Erich Schulz You can certainly say (I'd hope) in FHIR all the information you have noted using SNOMED, a medication code system, and the medication and encounter resources. Not making up a code for all the complexity you have in your quoted phrases is the whole point of doing interoperable modeling. There is a distinct pay-off for enduring the difficulty of consistent representation using codes and an agreed upon model. I'm sure you know this. That said, you have misrepresented my intent of saying if you use a code, you need to say what code system it came from. I see another discussion on this (see SSN) in the forum threads. Yes there are thousands of local codes - make them live in a local code system and keep track of it. And RANT I'm tired of hearing that no one does that so we won't start now. We need to grow up and start doing the right thing, not simply the easy thing.If you are participating in the development of FHIR - now is when those changes should occur.End RANT The improvement process can only start with us, right?
Erich Schulz (May 31 2016 at 22:03):
@Robert McClure heh - trust me I am well aware of the complexities :-) we will never elliminate local coding - yes I need to build a proper ontology service into the system - but currently I need to get a working system - there will also always be many decision points within a system (that maybe enumerated value sets in a UI drop down or allowed values in a variable somewhere, options in a switch statement) that dont really need encoding - any decions point in any kind of algorithmic decision support engine may have a score of binary decision points - these will be extraordinarily precise and context specific - the point being that not all things that are "encodable" must go into the ontology server and the boundary of what should and shouldn't will always be grey. That said I'm right with you! just gimme some time to catch up :-)
Last updated: Apr 12 2022 at 19:14 UTC
