oship-dev team mailing list archive

[Luciana Tricai Cavalini <lutricav@xxxxxxxxx>]

Hi Sergio and OSHIP-Dev,

Sergio M. Freire escreveu:
> Hi,
>
> I feel rather confortable with the archetype specification as it is.
I don't think we should change anything on the openEHR specifications 
(especially because we can't). This is something for us to discuss about 
the MLHIM specifications.
>  I won´t go into the philosophical discussions of what a concept is.
But that's what I would love to do, because I think we should consider 
including more epistemological/scientific rigueur to the specifications. 
Of course they are great the way they are right now, but they can be 
improved, and I would like to give my contribution to that. Being inside 
the academic world and having time and other conditions to develop those 
reflections as a scientific project, in my opinion, is something that 
gives us the priviledge of discussing in depht the immense philosophical 
background of the multilevel modeling approach.
I think it is possible to discuss those theoretical subjects along with 
the practical implementation of the specifications, especially because 
OSHIP 1.x must be 100% openEHR compliant, what's important for our proof 
of concept.
>  When Rigoleta and me designed the demographic archetypes we used and abused of archetype slots because it is a construct that expressed well what we meant. 
>   
This is something for me to think about, because your demographic 
archetypes are great, especially because they are openEHR *and* ISO 
compliant at the same time. That *might* demonstrate the conceptual 
differences between the demographic and the clinical models.
But then I go to the CKM and I download that body weight archetype with 
that slot for the scale, something there just doesn't sound good to me. 
Body weight is a well defined clinical concept, so it deserves an 
archetype. Scale is another well defined clinical concept, so it 
deserves another archetype. The body weight archetype and the scale 
archetype can be used in combination to other clinical concepts. Scales 
are not only used to weight bodies, otherwise it should be part of the 
body weight archetype, because it would be part of the body weight 
concept. So, why not combining those two archetypes in a template and 
just forget about the internal slot on the body weight archetype? I 
think this approach makes the knowledge modeling much easier for 
healthcare professionals.
> What are the practical reasons for discarding archetype slots? 
>   
For OSHIP 1.x, I can't see any. For the MLHIM specifications, I think we 
should keep discussing and thinking about moving forward.
Because I really think that isolating the healthcare concepts inside the 
archetypes and only allowing their combination inside the templates is a 
much "cleaner" approach that, I repeat, I think it could make more sense 
for healthcare professionals.

> What are the alternatives now? Are they better?
>   
Right now, as I said before, no alternatives, let's go 100% compliant to 
the openEHR specifications for OSHIP 1.x, and sorry if I am being 
repetitive about it, but I am thinking about the newbies and students, 
so I am just trying to be didactic. But I think we could take the 
opportunity of being developing a research project and allow ourselves 
to perform those experiments, because we have this freedom.
If they are better or not, there's only one way for us to know: by 
performing the experiments and testing our hypothesis. How could we do 
that? No other way: let's follow the openEHR Foundation principle #1: 
implementation, implementation, implementation. Our new approach for 
archetype governance, with expert panels and free and open debate and 
polling on HKCR, might bring more light to this subject. Only the 
development of the project will give us those answers, in my opinion.

Cheers, Luciana.

> Sergio
>
>
> ----- Mensagem original -----
> De: "Luciana Tricai Cavalini" <lutricav@xxxxxxxxx>
> Para: "OSHIP-Dev" <oship-dev@xxxxxxxxxxxxxxxxxxx>
> Enviadas: Sexta-feira, 7 de Maio de 2010 11:17:29
> Assunto: Re: [Oship-dev] Fwd: IHTSDO meeting - term binding presentation available
>
> Hi OSHIP-Dev,
>
> I'm going to express my opinion on what I feel comfortable about:
> MLHIM specifications' concepts should be clearer than the openEHR ones,
> that are still open to a few amount of misinterpretations.
> For me, an Clinical Constraint Definition (= "archetype") is like an
> atom, so it should be complete and self-contained. It should not allow
> slots. Templates are molecules, and the connections between archetypes
> needed to create those "molecules" are the slots in my opinion. So,
> slots should be limited to templates.
>
> Sorry for the chemical analogy...
>
> Debate! Debate! ;-)
>
> Cheers, Luciana.
>
>
> Tim Cook escreveu:
>
>
> Hi All,
>
> Below is a thread from the openEHR lists regarding terminology binding.
> It should be read by all addressed here.
>
> I have considered these issues in the past and since I am presenting
> MLHIM to a US company in two weeks with a focus on just this problem. I
> wanted to let you all know what I am 'planning' to put in the MLHIM
> draft specs.
>
> The problem that is most vexing is one of post-coordinated binding. This
> problem is closely related to what I am talked with some of you about
> before. The complexity and counter-intuitiveness of slots in concept
> constraint definitions (CCDs aka. archetypes).
>
> Given: an archetype is defined as being a "complete representation of a
> single clinical concept".
>
> Then: Why archetype slots? Everything for that concept SHOULD be a part
> of that CCD/archetype.
>
> Therefore: A CCD should be a complete clinical concept. If/when the
> concept is too broad to utilize pre-coordinated terminology, then it
> should be marked as ABSTRACT (in the object-oriented sense of the word).
> This allows a CCD to be created and then subclassed from (aka. archetype
> specialization) but it prevents that specific abstract CCD from being
> instantiated.
>
> Of course in the specs this will be expanded on so it makes more sense
> to new readers. But I wanted to pass this by knowledgeable people to get
> feedback. The concept of abstract schemas is support in XML schemas.
>
> Regards,
> Tim
>
>
> ---------- Forwarded message ----------
> From: Seabury Tom (NHS Connecting for Health) < tom.seabury@xxxxxxx >
> Date: Thu, May 6, 2010 at 11:32 AM
> Subject: RE: IHTSDO meeting - term binding presentation available
> To: For openEHR clinical discussions < openehr-clinical@xxxxxxxxxxxxxxx
>   
>
>
>
>
>
>
> Hi Mikael, Thomas
>
>
>
> There are certainly instances of sets being generated by authorities
> other than national release centres, ones that conform to the SNOMED CT
> guidance, which requires their identifiers include a recognised
> namespace.
>
> Two aspects of this topic are 1) that you need access to tools which
> allocate unique identifiers, in accord with the standard and 2) that the
> allocation of namespace identifiers cannot be assumed to be a
> free-for-all although at last count there were in the region of 110,
> some of which were allocated to individuals. To use a Namespace you are
> obliged to conform to the SNOMED CT licence conditions and similar good
> behaviour.
>
>
>
> Those with an interest in this topic may wish to join, for example, the
> SNOMED CT Implementation Special Interest Group via this link:-
>
> http://www.ihtsdo.org/join-us/help-improve-snomed-ct/
>
>
>
> To join an established Special Interest Group mail to: info(at)
> ihtsdo.org stating which group you wish to join,
>
> ‘Special Interest Groups (SIGs) are open and ongoing bodies that examine
> issues related to specified topics that are relevant to the IHTSDO and
> its members.’
>
>
>
> Tom Seabury
>
> IHTSDO
>
>
>
> From: openehr-clinical-bounces@xxxxxxxxxxxxxxx [mailto:
> openehr-clinical-bounces@xxxxxxxxxxxxxxx ] On Behalf Of Mikael Nyström
> Sent: 06 May 2010 16:51
> To: 'For openEHR clinical discussions'
> Subject: RE: IHTSDO meeting - term binding presentation available
>
>
>
>
> Hi Thomas,
>
>
>
> As another member of IHTSDO Technical Committee I would like to ask from
> where you have got your impression that RefSets should mainly be
> maintained by the national release centers, because that is not at all
> my impression. Some of the national release centers, like NHS in UK,
> maintain Subsets/RefSets, but I have never heard anything about that
> only the national release centers should create and maintain RefSets. My
> impression is that whoever that find it useful to create and maintain an
> own RefSet should be able to do it.
>
>
>
> The only requirement to create a RefSet is the technical requirement to
> have an own namespace to create the RefSet into. However, all
> organizations and persons with a valid SNOMED CT license can get an own
> namespace.
>
>
>
> (I have my own namespace, so if I would I could immediately produce and
> release as many RefSets that I want.)
>
>
>
> Greetings,
>
> Mikael
>
>
>
>
>
>
>
> From: openehr-clinical-bounces@xxxxxxxxxxxxxxx [mailto:
> openehr-clinical-bounces@xxxxxxxxxxxxxxx ] On Behalf Of Thomas Beale
> Sent: den 6 maj 2010 12:15
> To: openehr-clinical@xxxxxxxxxxx
> Subject: Re: IHTSDO meeting - term binding presentation available
>
>
>
> On 06/05/2010 08:48, Sebastian Garde wrote:
>
>
>
> Hi Thomas,
>
> do you know if there is a formal way of how RefSets (=the resulting
> Snomed CT codes etc.) and the RefSet query (=the query on Snomed CT to
> get to the RefSet) are expressed and shared?
>
>
> the ref set results are defined by Snomed RF2 ref set specs, now in
> draft. I don't know whether they are allowed to be shared outside
> IHTSDO, but will find out. The query language is still an open question.
>
>
>
> Similar to what is described here but based on RefSets:
> http://www.openehr.org/wiki/display/term/Ocean+Terminology+Query+Language+%28TQL%29
>
> I agree that RefSets are a good way forward, but they need to be
> available, reusable and sharable, etc.
>
>
> they do. The current IHTSDO thinking is that ref sets will mainly be
> defined by national release centres and maintained in the national
> extensions, with some major refsets being in the international release.
> I think this is far too restrictive a view, and that in future they will
> be defined and maintained in health care facilities, regional
> information centres and anywhere else that needs them. The IHTSDO
> representation and extension mechanism should be usable at all these
> levels. How it could be used for openEHR I have yet to find out, but am
> making enquiries as a member of the IHTSDO Technical Committee).
>
> - thomas
> ********************************************************************************************************************
>
> This message may contain confidential information. If you are not the
> intended recipient please inform the
> sender that you have received the message in error before deleting it.
> Please do not disclose, copy or distribute information in this e-mail or
> take any action in reliance on its contents:
> to do so is strictly prohibited and may be unlawful.
>
> Thank you for your co-operation.
>
> NHSmail is the secure email and directory service available for all NHS
> staff in England and Scotland
> NHSmail is approved for exchanging patient data and other sensitive
> information with NHSmail and GSI recipients
> NHSmail provides an email address for your career in the NHS and can be
> accessed anywhere
> For more information and to find out how you can switch, visit
> www.connectingforhealth.nhs.uk/nhsmail
>
> ********************************************************************************************************************
>
> _______________________________________________ openEHR-clinical mailing
> list openEHR-clinical@xxxxxxxxxxx
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
>
>
> -- Esta mensagem foi verificada pelo sistema de antiv�rus e
> acredita-se estar livre de perigo.
> _______________________________________________ Mailing list:
> https://launchpad.net/~oship-dev Post to : oship-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~oship-dev More help :
> https://help.launchpad.net/ListHelp
> -- Esta mensagem foi verificada pelo sistema de antiv�rus e
> acredita-se estar livre de perigo.
> _______________________________________________ Mailing list:
> https://launchpad.net/~oship-dev Post to : oship-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~oship-dev
> More help : https://help.launchpad.net/ListHelp
>
>   

--
Esta mensagem foi verificada pelo sistema de antiv�s e
acredita-se estar livre de perigo.