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 <[email protected]> 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 [email protected] 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 [email protected] > > wrote: > > > > > Hi Andrew, Chris ! > > > On Sat, 18 Aug 2018 12:17:45 +0100 (BST) > > > "[email protected]" [email protected] 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
