Re: [Health-dev] [task #15027] A discussion on integrating HL7 FHIR (and related) codesets into the data models

[Chris Zimmerman]

Hi!

Sounds good. I'll plan to start the conversation with SNOMED and hopefully 
start the basic work for the separate codeset module.

All the best,

C




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, November 25, 2018 12:08 PM, Luis Falcon <address@hidden> wrote:

> Hi Chris / Andrew / Community !
>
> Thanks for the feedback ! Yes definitely let's get the conversation
> starting. We just have to make sure that is SNOWMED use is Libre under
> all scenarios, otherwise it won't fit.
>
> All the best,
> Luis
>
> On Thu, 22 Nov 2018 20:55:26 +0000
> Chris Zimmerman address@hidden wrote:
>
> > Hi Luis, Andrew!
> > Sorry to resurrect this old topic but I wanted to slowly get started
> > on these goals.
> > I would be glad to start the conversation with snomed about use and
> > licensing. There is some concerning wording in that
> > Humanitarian/Charitable exemption - "Any programs/material encoded
> > with SNOMED CT will be deemed as SNOMED International's property."
> > However, starting the dialogue is important.
> > On the other hand, although SNOMED CT is quite comprehensive there
> > are areas it does not cover. For example, insurance type codes are
> > defined by FHIR (with no equivalent in SNOMED, to my knowledge):
> > -PUBLICPOL
> > -public healthcare
> > -Insurance policy funded by a public health system such as a
> > provincial or national health plan. Examples include BC MSP (British
> > Columbia Medical Services Plan) OHIP (Ontario Health Insurance Plan),
> > NHS (National Health Service).
> > There are many of these niche codesets which can be, as both of you
> > suggested, added via a separate module. Adding a 'local code' column
> > for ease of transition is a great idea. And even if other codesets
> > ultimately supersede them (SNOMED, etc), having these
> > selections/choices as a separate module makes updating much simpler.
> > All the best,
> > C
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Tuesday, August 21, 2018 8:36 AM, Luis Falcon address@hidden
> > wrote:
> >
> > > Hi Andrew, Chris !
> > > On Sat, 18 Aug 2018 12:17:45 +0100 (BST)
> > > "address@hidden" address@hidden wrote:
> > >
> > > > Hi Chris
> > > > In the SHORT term I think that GNU Health might need to continue
> > > > using 'local codesets' with the option of also using a SCTID
> > > > (SNOMED CT Identifier) in the same database table:
> > > > Text description | Local code | SCTID
> > > > oral | PO | 123456789
> > > > intravenous | IV | 987654321
> > > > In the medium term I think that GNU Health should be configured
> > > > with the option of using/linking to a SCT TERMINOLOGY SERVER.
> > > > This could possibly be a new GNU Health module or could just be a
> > > > web link to an 'open source' terminology server.
> > > > An increasing number of countries are now licensed to use SNOMED
> > > > CT and those very low income countries can apply for the SCT free
> > > > license option.
> > > > Hope I have made myself clear.
> > > > What do you think Luis?
> > > > Andrew
> > >
> > > Agree with both of you.
> > > In our case, I believe we should be able to integrate it, under
> > > exemption 3[1].
> > > "Humanitarian/Charitable use: Offered strictly to not for profit
> > > organizations who would like to use SNOMED CT non-commercially, for
> > > the betterment of people living in rural areas and/or poorer
> > > countries."
> > > We can talk to them and make sure we are in the same track about
> > > providing unversality in healthcare.
> > > In any case, in my opinion is to create a separate module, that
> > > would allow to plug the datasets if the implementation context
> > > requires it.
> > > Let me know your thoughts
> > > 1.-
> > > https://www.snomed.org/snomed-ct/get-snomed-ct