More generic reference model

Clinical (archive)
81

Thomas, from my phone, short. The Sct integration as I propose is optional. No changes in openehr specs is needed. No software change is needed. It are only additions except for two minor issues.

So if organization’s do not want to use Sct, or are not allowed to use it, they still can keep on using Openehr. So you don’t need to solve all those mappings before integrating Sct. Organizations can start right now, I can help, or another developer can help building the additional needed software and the most beautiful, an archetype editor based on SCT.

82

One solution would be to do everything on SCT and use mappings to the other terminologies (most are really classifications and have a much simpler internal structure).

83

Even better, Pablo, it uses SCT, and does not stand in the way of other terminologies, it is a parallel process which fits inside the OpenEhr specs.

I tried to explain it before, maybe I did not well explain it. Tell me if so.

So, you can keep on proceeding as you were already doing, but you can add something which unlockes the SCT potential.

I explained it on my blog. Please comment on that, maybe you do not agree, if so, then I want to hear about that.

http://www.bertverhees.nl/archetypes/needed-run-snomed-ct-expression-constraints-openehr-aql/

http://www.bertverhees.nl/archetypes/snomed-ct-expression-constraints-openehr-aql-part-2/

84

It is definitely possible - here's a pre-release version of our Shrimp browser using only FHIR APIs http://ontoserver.csiro.au/shrimp🔥/

(Hope that Unicode works :slight_smile:

Michae

85

Dear Grahame,

I modeled ICF to an archetype for my ice bucket challenge, but forgot to publish on CKM.

Do you need this?

Shinji Kobayashi

86

Hi Michael, I have seen it before a few months ago, a great tool. Very innovative. And easy to work with. I do not often see such a good work.

I will check it out today again, thanks for posting

Bert

87

Can everyone who has concrete ideas on ways forward make an effort to update the wiki page we created for this, and/or add to the Questions facility for some of the useful peripheral questions that have been answered along the way.

The Specifications Editorial Committee will look at these issues in the near future, but some coherent material would be very helpful.

thanks

  • thomas
88

Grahame,

can you post a URL to that functionality / spec?

thanks

- thomas

89

Michael,

Very nice tool, thanks for the link. One small comment - in a few places like where the SCT edition is chosen, something more human-readable than a concept code would be nice. Other than that, it’s a very nice tool.

Can you give a quick idea on what the main intended eventual use is? Browsing by terminology authors? Browsing by users? Can it be used for ref-set perusal - i.e. where you choose ‘SNOMED CT’, would it one day be possible to load just a ref-set there? By ref-set I mean something structurally the same as SNOMED itself, with all relationships potentially, but just reduced content according to a ref-set def.

  • thomas
90

I will give it a new try, I have explained it so much, I know where people stop to follow the explanation.

91

Thanks Bert,

The difference between this one and the old one is that the old one was using our old terminology server through its proprietary APIs.

This new one is using generic FHIR APIs and can be pointed at an arbitrary FHIR Server that (correctly) implements the terminology services part of the FHIR spec >= 1.6.0

michael

92

I rewrote the part, I think it is easier to understand now. When someone will improve it, I am available to explain when something appears to be unclear.

https://openehr.atlassian.net/wiki/display/spec/Terminology+Querying+for+AQL

93

http://hl7.org/fhir/2016Sep/valueset-operations.html#expand, see params offset and count

Grahame