[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Health-dev] [task #15027] A discussion on integrating HL7 FHIR (and
Re: [Health-dev] [task #15027] A discussion on integrating HL7 FHIR (and related) codesets into the data models
Fri, 30 Nov 2018 04:58:39 +0000
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,
‐‐‐‐‐‐‐ 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,
> 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.
> > > "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