Re: MEDINFO 2019, Lyon, France.

[Grahame Grieve]

>
> I think HL7 has little interest in working with any other SDOs/orgs, and
> mainly appears to be interested in keeping the FHIR hype going.
>

I thought about ignoring this... but no, I'll bite. gently. There are some
at HL7 like this, but actually we're deeply engaged
with many other SDOs and Orgs. That is driven by global engagement, and
openEHR just doesn't have have the
geographical breadth (interest in engagement is from very specific
jurisdictions). But that doesn't mean that we
wouldn't be interested in doing this. However I won't be at Lyon - I'm at
my limit for travel. I'm still looking into
who is going from HL7's side.

But as I said before: if we were going to do this, we'd actually have to
something meaningful to say that
we haven't already said. That'd require some actual work... not sure who's
going to do that. I'm interested
in it, but it's hard to see it getting on my priority list. :-(

Grahame
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: MEDINFO 2019, Lyon, France.

[Grahame Grieve]

>
> Over the years I’ve attended so many Ed & Chuck sessions where they have
> provided informative updates on HL7 activities.
>

ok.


> Perhaps you missed my suggestion for a “Panel exploring how openEHR, FHIR
> & SNOMED work together – a cross SDO panel”?
>

I did miss that, yes.

> Why don’t you volunteer to participate?
>

well, I might. though we'd need some actual content that we don't presently
have. But I don't know whether I'll be funded for that meeting. I'll
discuss at the next HL7 meeting.

Grahame
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: MEDINFO 2019, Lyon, France.

[Grahame Grieve]

>
> It will likely be a useful counter to the usual HL7 panels that run each
> conference.
>

out of interest, what are those?

do you want to continue to act 'counter' to HL7, or is there a different
future?

Grahame
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: Questionnaires

[Grahame Grieve]

hi Heather

> A generic question/answer pattern is next to useless - interoperability
is really not helped

I think you should rather say "A generic question/answer pattern is only
useful for exchanging the questions and answers, and does not allow re-use
of data". This is not 'next to useless for interoperability', just not fit
for any wider purpose

Grahame


On Mon, Jun 5, 2017 at 3:51 PM, Heather Leslie <
heather.les...@oceanhealthsystems.com> wrote:

> Following Thomas’ suggestion re a separate thread:
>
>
>
> I wrote a blog post in 2014 which still reflects our current thinking re
> questionnaires: https://omowizard.wordpress.com/2014/02/21/the-
> questionnaire-challenge/
>
>
>
> Our experience is that the data is the priority and so we want to focus on
> questionnaires to support capture of good quality data.
>
>
>
> If you want to try to capture data from the majority of existing
> questionnaires then good luck – questionnaires notoriously ask questions
> badly, conflating multiple concepts into one question, Boolean True/False
> when there are other ‘shades of gray’ etc. They work variably as far as
> human interpretation but usually very badly wrt computer interpretation.
>
>
>
> We do have experience in taking previous paper questionnaires, analysing
> the data requirements sought in terms of what we want to persist and then
> we design the UI/questions to match the data desired and/or suggesting the
> UI might show a questionnaire but each question the clinical data is
> actually recorded using core archetypes – for example “Do you have
> diabetes?” – ‘Yes’, is recorded using the value ‘Diabetes’ in the
> EVAL.problem_diagnosis and ‘No’ is recorded in the matching exclusion
> archetype. This creates real clinical data that can be used as part of a
> health record rather than create an electronic checkbox version of the
> original paper questionnaire which will never be used again, but capture
> dust in our EHR’s virtual archives.
>
>
>
> In summary:
>
>- A generic question/answer pattern is next to useless -
>interoperability is really not helped, especially if both the question and
>answer has to be managed in the template. We have tried many variations of
>this in the past, some of which were uploaded into CKM and subsequently
>rejected.
>- Lock in those questionnaires that are ubiquitous, evidence based,
>validated as OBSERVATION archetypes and share them in the international CKM
>– eg AUDIT, Glasgow coma scale, Barthel index, Edinburgh post natal
>depression scale – there are many examples in CKM.
>- Lock in local questionnaires that are going to be reused in your
>organisation, region or jurisdiction even though they may not be reusable
>elsewhere. They will provide some interoperability even if might only be
>appropriate within one clinical system or national CKM. An example is the
>Modified Early Warning Score/National Early Warning Score – there are a few
>different variations used in different locations and whether they should
>all be in the international CKM is still not clear.
>
>
>
> BTW Questionnaires should be modelled as OBSERVATIONs (ie evidence that
> can be collected over and over again using the same protocol) not
> EVALUATIONS (as they are not meta-analysis nor summaries).
>
>
>
> Regards
>
>
>
> Heather
>
>
>
> *From:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org] *On Behalf Of *Pablo Pazos
> *Sent:* Thursday, 1 June 2017 12:58 AM
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* Re: Reports - a new openEHR RM type?
>
>
>
> Besides specific ways to model questionnaires, my questions is if our
> openEHR clinical modelers have a pattern to represent questionnaires using
> the openEHR information model.
>
>
>
> On Wed, May 31, 2017 at 3:37 AM, GF  wrote:
>
> There are several kinds of context archetypes/templates and their
> meta-data are used for:
>
> - de novo data - re-used data
>
> - step in the clinical treatment model (observation, assessment/inference,
> planning, ordering, execution)
>
> - kind of interface it is designed for (data presentation on a screen,
> data capture, database store/retrieve, CDSS, …
>
>
>
> Each Template needs to capture all this and is a Composition.
>
> All these contexts are characteristics of a Composition in the end.
>
>
>
> Questionnaires are in essence a tool that classifies information.
>
> And sometimes it transforms a set of responses into an aggregated
> value/code
>
> The questionnaire can be treated as any classification, meaning we need to
> de fine inclusion and exclusion criteria,
>
> and possible results per question can be a quantitative result (number,
> PQ, code), or a semi-quantitative result (high, low), or a qualitative
> result (present/ not present).
>
> Semi-Qualitative results need, inclusion/exclusion criteria and a
> definition of what the norm/population is is about 

Re: Two LOINC codes for one lab-item

[Grahame Grieve]

bit of both - there are some institutions running on a terminology server
that can manage those kind of things, and others have to do manual
conversion. But terminology servers are gradually becoming more commonly
deployed (all the good ones I know of are free).

Grahame


On Fri, Feb 17, 2017 at 8:58 PM, Ian McNicoll  wrote:

> Hi Robert,
>
> Thanks for the input.  This is going to be a universal issue, however and
> wherever we are trying to aggregate bits of 'clinically identical' lab data
> as-per your example.
>
> I am interested in how this is done now, as LOINC is not extensively used
> in the UK outside individual institutions, and my understanding is that the
> LOINC terminology carries enough relationship metadata to allow
>
> 2160-0 Creatinine [Mass/volume] in Serum or PlasmaCreatinine
> Qn mg/dL
> 14682-9 Creatinine [Moles/volume] in Serum or Plasma  Creatinine
> Qn umol/L
>
> to be queried/inferenced as 'Creatinine Serum or Plasma' but this would
> require a LOINC-aware terminology server.
>
> or do folk just manually document the sets of terms to be queried?
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859 <+44%207752%20097859>
> office +44 (0)1536 414994 <+44%201536%20414994>
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 16 February 2017 at 13:51, Robert Hausam  wrote:
>
>> In recent months I've had some discussions with Dan Vreeman at
>> Regenstrief about the need to be able to group or aggregate "clinically
>> equivalent" LOINC codes (however "clinically equivalent" is defined - mol
>> and mass is one obvious case).  The original impetus for our discussion
>> isn't being pursued on my end at the moment, but Dan did say that
>> Regenstrief is embarking on an effort of their own to develop the
>> capability for doing something like this.  I am sure that they would be
>> interested in hearing about use cases that are being identified that need
>> this capability (and also about anyone with an interest in helping them
>> with getting the work done).
>>
>> Rob
>>
>> On Thu, Feb 16, 2017 at 6:23 AM, Wouter Zanen > > wrote:
>>
>>> The use case discussed was our use case. All that has been explained
>>> makes perfect sense from a lab perspective (Mol and Mass are different
>>> test), however in our use case we do need to aggregate them.
>>>
>>> In our case it is allowed to report have for example createnine in both
>>> mg/dl and mmol/l, in the software application it will be one field with a
>>> choice for the unit, we receive info from multiple labs in europe). We are
>>> also looking for the possibility for electronic exchange of HL7v2 messages
>>> in the future. We use the lab test observation (inlcuding specimem
>>> details)  and lab test panel to record the test result. We try to bind with
>>> both SNOMED and LOINC (being flexible), on a template level I see only two
>>> solutions:
>>>
>>> I now see two options:
>>>
>>>- Either we don't bind to LOINC and MAP Loinc codes in the mapping
>>>software we inevitable are going to need to process the HL7V2 message.
>>>Result is one archetype with both mol and mass units.
>>>- Or we invent a testfinding container archetype (Called Creatinine
>>>that binds to Snomed) and under that we have two test panel archetypes 
>>> for
>>> Mol and Mass. This makes building the app more difficult but at least we
>>>know the composition is related to Createnine.
>>>
>>> Currently we prefer solution 1.
>>>
>>> Best regards,
>>>
>>> Wouter Zanen
>>>
>>>
>>>
>>> De inhoud van dit bericht is uitsluitend bestemd voor de geadresseerde
>>> en kan vertrouwelijke en/of persoonlijke informatie bevatten. Als dit
>>> bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de
>>> afzender te melden en het bericht (inclusief bijlagen) uit uw systeem te
>>> verwijderen. Eurotransplant staat door de elektronische verzending van dit
>>> bericht niet in voor de juiste en volledige overbrenging van de inhoud,
>>> noch voor tijdige ontvangst daarvan. Voor informatie over Eurotransplant
>>> raadpleegt u: www.eurotransplant.org.
>>>
>>>
>>>
>>> This message is intended for the addressee's eyes only and it may
>>> contain confidential and/or personal information. If you are not the
>>> intended recipient, you are hereby kindly requested to notify the sender
>>> and delete this message (including attachments) from your system
>>> immediately. In view of the electronic nature of this communication,
>>> Eurotransplant is neither liable for the proper and complete transmission
>>> of the information contained therein nor for any delay in its receipt. For
>>> information on Eurotransplant please visit: www.eurotransplant.org
>>>
>>> >>> Ian 

Re: More generic reference model

[Grahame Grieve]

it's possible to use SCT more infrastructurally in FHIR, but this is
something we are only now exploring with IHTSDO staff + other interested
parties

Grahame


On Sun, Sep 4, 2016 at 7:58 PM, Bert Verhees  wrote:

> Hi Ian, thanks for attaching that presentation, I saved it.
>
> But I also read it, but I must admit, that is a bit hard, presentations
> are always a bit hard to read, the person who gives the information adds
> value.
> But still, very informative.
>
> And at the same time, the difference between FHIR and OpenEHR came to
> mind, and also the difference purpose of SNOMED in both. FHIR is a message
> format, while OpenEHR defines a storage environment complete with
> possibilities for a query engine, facilities for datamining, templates for
> screens, generating FHIR messages, etc.
>
> In FHIR SNOMED is mainly be used, as I understand, to refer to SNOMED,
> conceptID's, Refsets, Compositional Grammar, Constraint Language. It are
> references to explain data, or the environment of the message producer.
> While in OpenEHR, it can be used to facilitate the other features which
> can come out of a full featured OpenEHR environment. It are these
> facilities where I refer to when I talk about SNOMED in OpenEHR integration.
>
> So I think it is another subject. But still, I am very grateful for the
> presentation. I almost never have chance to visit those occasions where
> these presentations are given.
>
> Bert
>
>
>
> On 03-09-16 20:43, Ian McNicoll wrote:
>
> I found this excellent document from GEHCO gehco.org. It refers mostly to
> FHIR but has some examples from openEHR, and I think the challenges and
> principals are pretty well identical.
>
> http://www.gehco.org/wp1508/wp-content/uploads/2016/06/
> Powerpoint-FHIR-and-SNOMED-V0-92.pdf
>
> I know CIMI has a key aim of trying to create the kind of iso-semantic
> models that Bert is advocating, and while this is a laudable objective, the
> challenge should not be under-estimated.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
> On 3 September 2016 at 17:34, Bert Verhees  wrote:
>
>> On 03-09-16 18:17, Thomas Beale wrote:
>>
>> Bert,
>>
>> doing most of what you want should come in AQL, e.g. the following in a
>> WHERE clause is already possible.
>> SELECT
>> e/ehr_status/subject/external_ref/id/value,
>> diagnosis/data/items[at0002.1]/value
>> FROM
>> EHR e
>> CONTAINS Composition c[openEHR-EHR-COMPOSITION.problem_list.v1]
>> CONTAINS Evaluation diagnosis[openEHR-EHR-EVALUATI
>> ON.problem-diagnosis.v1]
>> WHERE
>> c/name/value='Current Problems'
>> AND diagnosis/data/items[at0002.1]/value/defining_code *matches* {
>> http://snomed.info/id/4257030190487|cancer Dx refset|}
>>
>>
>> That is a very OpenEHRish way to do it, is comparing the code.
>>
>> But what if you also want to find the subtypes, lungcancer (30
>> sub-types), etc, if you want to know about SNOMED attributes.
>> For that purpose is the Expression Constraint language, and you need to
>> query the terminology to know what you need to compare your data with.
>>
>> The best way to do it is not invent another way to do it, but embed that
>> language.
>> http://doc.ihtsdo.org/download/doc_ExpressionConstraintLangu
>> ageSpecificationAndGuide_Current-en-US_INT_20150820.pdf
>> When that is done well, you have the full power in one move.
>>
>> One interesting question is whether 'inline' refset definitions would be
>> allowed, e.g. using the SNOMED constraint grammar. We probably should add
>> this to AQL as a plug-in syntax, since IHTSDO standardised it
>> .
>> What the solution is for ICDx I don't know.
>>
>>
>> I don know either.
>>
>> There is more then just a plugin which does some separate work. Because
>> the ECL also works on subtypes and attributes, and the attributes are not
>> available. AQL must deliver them to the SNOMED engine, because they are on
>> another path. There is code infrastructure needed.
>>
>> For example: Find systolics higher then 165, in the archetype the type of
>> the measurement can be in another element then the value of the measurement.
>> This mapping between SNOEMD attributes and where they are in the
>> archetypes must be done in some elegant way.
>>
>> The main thing to understand is that if a SNOMED or ICD code for say
>> leukaemia is found in EHR data, the code alone doesn't tell you the
>> epistemic status, i.e. the kind of statement being made - i.e. current
>> diagnosis, no risk of, risk of, fear of ... etc. Querying properly means
>> understanding where in the 

Re: HL7 and negation

[Grahame Grieve]

>> There is a specific flag on list for noting the clinically meaningful 
>> statement, but what we've found is that almost all systems treat the 
>> statement of no allergies in an allergy record as an explicit statement
> 
> that sounds right.
> 
>> Btw, I don't think that the statement of no allergy is a case of a negation 
>> statement
> 
> Is there any online summary of how negations, exclusions etc are understood 
> in FHIR?

No, there's no summary at all. Our general approach is that the theory of 
negations from terminfo generally holds, but a thorough survey of what existing 
systems are doing (or, failing that, a series of connectathons) generally 
establishes that there are practical restrictions created by poor clinical 
record keeping that point to a different course of action. 

Also, we consider other approaches, including the openehr exclusion model 
approach, which is also a part of FHIR. 

Grahame 
> 
> - thomas
> 
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: HL7 and negation

[Grahame Grieve]

> Aside: apparently the FHIR approach to representing things like 'no known 
> allergies' is to infer it by seeing if an allergies list is empty or not. 
> That sounds like a bad idea to me. If 'no known allergies' is understood as a 
> clinically meaningful statement made by e.g. a GP (based on reliable 
> knowledge about the patient), checking for a list being empty in some EMR 
> system isn't at all the same thing. All that latter does is establish that no 
> allergies have been recorded on this particular system.

Well, that would be a bad idea. But that's ok because that's not what we do ;-)

There is a specific flag on list for noting the clinically meaningful 
statement, but what we've found is that almost all systems treat the statement 
of no allergies in an allergy record as an explicit statement 

Btw, I don't think that the statement of no allergy is a case of a negation 
statement

Grahame 
> 
> - thomas
> 
>> On 08/06/2016 07:54, GF wrote:
>> 
>> 
>> Dear Colleagues,
>> 
>> HL7 is thinking about the problem of negation.
>>  http://wiki.hl7.org/index.php?title=Negation_Requirements
>> The group discussing it created a document with negation use cases.
>> 
>> My questions are:
>> - Can you let us know your reaction to this list of use cases?
>> And
>> - How should ‘negation’ be handled the best in respect of semantic 
>> interpretability?
>> 
>> My personal opinions:
>> - the boolean should not be used
>> - try to translate the ‘negation’ problem into ‘presence and absence’. A 
>> concept is or is not present, a numeric result is of is not present.
>> - do not use pre- and post co-ordinated concepts using SNOMED but use the 
>> SNOMED primitives.
>> 
>> I’m curious to learn what your opinion is.
> 
> ___
> openEHR-clinical mailing list
> openEHR-clinical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

Re: openEHR-Based PhD Thesis Successfully Defended

[Grahame Grieve]

hi Nadim

FHIR was created July 2011, but you couldn't possibly have used it as a
base for this kind of PhD until maybe this year.

btw. well done.

Grahame

On Thu, Mar 10, 2016 at 9:48 PM, Nadim Anani  wrote:

> Dear John,
>
>
>
> Thank you very much!
>
>
>
> When I started my PhD in 2011 FHIR hardly existed/did not exist (I think).
>
>
>
> Also, I name other reasons for the choice: “*We chose to work with
> openEHR in this thesis in order to set a research scope, and because of the
> advantage of freely available and open-sourced resources. We had also
> gained some experience with and knowledge in openEHR prior to the start of
> this project. At the same time, this thesis’ findings can serve as a basis
> for comparisons with modelling and implementation of computerised clinical
> guidelines using other standard specifications.*”
>
>
>
> Does that help?
>
>
>
> Sincerely,
>
> Nadim
>
>
>
> *From:* George John (HEALTH AND SOCIAL CARE INFORMATION CENTRE) [mailto:
> john.geo...@hscic.gov.uk]
> *Sent:* den 10 mars 2016 11:43
> *To:* For openEHR technical discussions; Nadim Anani; For openEHR
> clinical discussions; For openEHR implementation discussions (
> openehr-implement...@lists.openehr.org)
> *Subject:* RE: openEHR-Based PhD Thesis Successfully Defended
>
>
>
> Nadim,
>
>
>
> Congratulations on successfully defending your PhD.  You mentioned that
> you chose to work with OpenEHR due to the advantage of freely available and
> open-sourced resources.  My interpretation is that had you worked with
> another interoperability specification, like HL7 FHIR, then the  open
> sourced resources and tooling etc… would have been less freely available,
> implying that OpenEHR is easier to work with and the software tooling costs
> less than HL7 FHIR.  Please can you clarify this?
>
>
>
> Kind Regards
>
>
> John
>
> John George
> Technical Modeller
> Architecture, Standards and Innovation
> Health & Social Care Information Centre
> Vantage House LEEDS LS1 4HT
>
>
> Tel: 0113 397 4193
> www.hscic.gov.uk 
>
>
>
> For general enquiries please call *0300 30 34 777 *or email
> enquir...@hscic.gov.uk
>
>
>
>
>
>
>
>
>
> *From:* openEHR-technical [
> mailto:openehr-technical-boun...@lists.openehr.org
> ] *On Behalf Of *Nadim Anani
> *Sent:* 10 March 2016 09:29
> *To:* For openEHR technical discussions; For openEHR clinical
> discussions; For openEHR implementation discussions (
> openehr-implement...@lists.openehr.org)
> *Subject:* RE: openEHR-Based PhD Thesis Successfully Defended
>
>
>
> Thanks Koray and thank you for this nice initiative J!
>
>
>
> Kind regards,
>
> Nadim
>
>
>
> *From:* openEHR-technical [
> mailto:openehr-technical-boun...@lists.openehr.org
> ] *On Behalf Of *Koray Atalag
> *Sent:* den 10 mars 2016 00:43
> *To:* For openEHR clinical discussions; For openEHR implementation
> discussions (openehr-implement...@lists.openehr.org); For openEHR
> technical discussions (openehr-techni...@lists.openehr.org)
> *Subject:* RE: openEHR-Based PhD Thesis Successfully Defended
>
>
>
> Bi congrats Nadim – FYI your thesis
>  is already
> accessible from openEHR Research Library
>  on Zotero.
>
>
>
> Cheers,
>
>
>
> -koray
>
>
>
> *From:* openEHR-clinical [
> mailto:openehr-clinical-boun...@lists.openehr.org
> ] *On Behalf Of *Nadim Anani
> *Sent:* Thursday, 10 March 2016 4:21 a.m.
> *To:* For openEHR clinical discussions (openehr-clinical@lists.openehr.org);
> For openEHR implementation discussions (
> openehr-implement...@lists.openehr.org); For openEHR technical
> discussions (openehr-techni...@lists.openehr.org)
> *Subject:* openEHR-Based PhD Thesis Successfully Defended
>
>
>
> Dear all,
>
>
>
> Following Diego’s email, I would like to also announce my successfully
> defended PhD thesis (on the 12th of February 2016):
> https://openarchive.ki.se/xmlui/handle/10616/44956
>
>
>
> This thesis explores ways of how openEHR can come into evidence-based
> practice via clinical practice guidelines. It covers the following in
> essence, amongst some other things:
>
>
>
> -  It proposes a method for representing guidelines based on
> CARE_ENTRY types, the so-called Care Entry-Network Model.
>
>
>
> -  It gives one of the first ever detailed accounts of how the
> openEHR-based Guideline Definition Language (GDL) works.
>
>
>
> -  It conducts the first ever GDL-based study using patient data
> from a registry.
>
>
>
> -  The latter effort, using the Safe Implementation of Treatments
> in Stroke (SITS) international patient data registry, leads to real
> clinical findings.
>
>
>
>
>
> Sincerely,
>
> Nadim
>
>
>
>
>
>
>
>
>
> Nadim Anani, PhD
>
> Centrum för hälsoinformatik / Health Informatics Centre (HIC)
>
> LIME

Re: Alive vs Dead

[Grahame Grieve]

 Hi Tom

>
>-
>hL7v2 messages indicate changes of state in things; and I think will
>be mainly ADT oriented, i.e. correspond to the administrative change to the
>openEHR demographic data
>- FHIR's view is a query - meaning depends on what resource it is
>coming from; it could be administrative or clinical event (Grahame?)
>
>
yes. administrative, completely aligned with earlier HL7 content, which is
all administrative.
I've heard some talk about doing death report as a profile on CDA
occasionally, but CDC are now looking at using FHIR as part of
rationalising their process for death notification reporting. But this is
just a variation on a clinical event summary, with a complicated
composition process with multiple different authors and attestation thrown
in.

Grahame
___
openEHR-clinical mailing list
openEHR-clinical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

openEHR-clinical Digest, Vol 35, Issue 21

[Grahame Grieve]

hi

 If you?d like this community to participate, perhaps an invitation on
behalf would encourage an active joint participation.

well, consider yourself invited, though I'm not exactly sure what kind of
invitation you want here.

k. so I grabbed some time to summarise things because we've got to a stable
point.

Looking through the tasks that have been recorded against the
AllergyIntolerance resource:

http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdittracker_item_id=3008start=0:
revise the definitions of the criticality values. The upshot was these
definitions:

HIGH -   Exposure to substance may result in a life threatening or organ
system threatening outcome.
LOW ?   Exposure to substance unlikely to result in a life threatening or
organ system threatening outcome.
Unable to Determine ? Unable to assess with information available.
Unknown ? A proper value is applicable but it is not known.

http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdittracker_item_id=5322start=0
- add 'reporter' -aka informant. I think this is already in the OpenEHR
reference model

http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdittracker_item_id=5724start=0
- cater for 'recorded in error' - I think this is inherent in the openEHR
reference model?

http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdittracker_item_id=5737start=0
- argument about status values and records. I'm not going to precis this
here; it's an open issue. This community might want to comment, though I'm
not entirely sure how well the issue translates in a pure archetype context

http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdittracker_item_id=5820start=0
- how do you use comments vs description? At the least, the archetype needs
better definitions to differentiate these.


There's been other ongoing discussions about the comparison with CCDA
and/or clinical practice in USA (at least). There's something solid there
which makes the existing design of both the archetype and resource in need
of redesign. I'll be launching discussion of this issue next week on
several HL7 lists. Perhaps I should cross-post here too?

Grahame





On Thu, Mar 26, 2015 at 5:20 PM, Heather Leslie 
heather.leslie at oceaninformatics.com wrote:

  Hi Grahame,



 We very much understand that you are being pulled in gazillions of
 directions at present with the explosion of FHIR on all fronts (excuse the
 pun - I?m sure you?re used to them now) but we are all trying to respond to
 the needs of our respective communities.



 I too would be extremely disappointed if this collaboration had to be
 abandoned. We have been so pleased to see this collaboration start off so
 well, and it really is ground breaking for many reasons. However, from a
 practical point of view, our last review was completed at end of November
 and we have been very patient while waiting for your end to be ready to
 proceed. The patience is not so unreasonably now evolving to some
 impatience, I guess.



 We are happy to explore all alternatives to try to progress this in a
 timely manner for all parties ? please suggest an approach and a timeframe.
 We have all our reviewers ready and looking forward to ongoing
 participation.



 If the worst happens and we can?t continue with this particular model, the
 progress that we have made to date will go a long way to ensure that the
 majority of the Adverse Reaction archetype and FHIR resource are well
 aligned, especially in the areas most critical and relevant to support
 interoperability at this time. And of course we can all learn from the
 experience such that when we look to do this next time we might all be
 wiser and clearer in how to manage it for all stakeholders.J



 BTW I?m not sure how many openEHR email listers are aware of the HL7
 conversations that you refer to. Ian and I certainly drop in on them on
 occasions, but we don?t regularly monitor them. If you?d like this
 community to participate, perhaps an invitation on behalf would encourage
 an active joint participation.



 Kind regards



 Heather



 *From:* openEHR-clinical [mailto:
 openehr-clinical-bounces at lists.openehr.org] *On Behalf Of *Grahame Grieve
 *Sent:* Saturday, 14 March 2015 5:25 PM
 *To:* For openEHR clinical discussions
 *Subject:* Re: openEHR-clinical Digest, Vol 35, Issue 21



 hi Heather



  We are attempting to work with the FHIR/HL7 patient care team for the
 Adverse Reaction archetype at the moment. At present the review is
 effectively stalled while Grahame is trying to harness a collective
 response. This has been the situation since mid November and unfortunately
 rapidly becoming an unworkable proposition.

  There are three different problems here

 * I personally overcommitted in this regard. I should have been pro-active
 in this process, and I regret that I didn't

 * it's hard to impose arbitrary deadlines on a continuous process

 * it's erroneous to think

openEHR-clinical Digest, Vol 35, Issue 21

[Grahame Grieve]

hi Heather

We are attempting to work with the FHIR/HL7 patient care team for the
 Adverse Reaction archetype at the moment. At present the review is
 effectively stalled while Grahame is trying to harness a collective
 response. This has been the situation since mid November and unfortunately
 rapidly becoming an unworkable proposition.

There are three different problems here
* I personally overcommitted in this regard. I should have been pro-active
in this process, and I regret that I didn't
* it's hard to impose arbitrary deadlines on a continuous process
* it's erroneous to think that the communications in a joint process are
all one way. Ian has been involved in the HL7 discussions, but I have
missed you from the process

It would be disappointing if we couldn't keep things together from here.
Not only is it a nice position, the joint work has proven robust against
criticism, but not beyond change proposals, and there are a few. In
particular, I think that we need to invest in more work on the way negation
works; I have a bunch of research on negation in the real world to bring
together and contribute, hopefully next week.

In terms of rectification, it would certainly help to remove me from the
loop  - to find someone else to catalyse the interaction from the HL7 side.

Grahame
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20150314/c1d60a95/attachment.html

The joint openEHR/FHIR review of Allergy/Intolerance is open

[Grahame Grieve]

hi All

We have opened the joint openEHR/FHIR review of Allergy/Intolerance:

http://omowizard.wordpress.com/2014/07/11/inaugural-joint-archetype-review-by-hl7-openehr/
http://www.healthintersections.com.au/?p=2169

The review is open until July 28th. We would like to encourage
everyone to contribute to the review; whether you are a clinician, a
programmer, a systems analyst. Clinicians, it would be great if you
can reach out to your systems vendor and encourage them to
participate.

I particularly want to thank both Heather Leslie and Ian McNicoll for
putting an immense amount of work into preparing for this joint
review. (which means I also need to recognise Russ Leftwich, who also
put a great deal of time and energy into the process too)

Grahame

note: my blog post includes some helpful information for the HL7
community to engage with the review, and documentation of the CKM sign
up process. I'm planning to document the review process, but I haven't
got to that yet.

Fwd: Joint OpenEHR / FHIR review of Allergy-related Resources

[Grahame Grieve]

Hi Everyone

Just a heads up to what is coming in the near future:
http://www.healthintersections.com.au/?p=2137

One of us (Heather Leslie or I) will post more about this shortly.

Grahame
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20140603/5d78d424/attachment.html

Complications in an event

[Grahame Grieve]

hi

The principle concern I had was definitional - did the definition of
problem preclude it's use for complications of an event. There's a notion
of ongoing-ness hinted at in the definition, but nothing explicit. And
there's the question about whether (or which) complications of an event
have ongoing implications or not.

Clearly there's no definitional issue, and so I'm fine with that. Regarding
the other discussion - since complications can indeed be real ongoing
concerns, I think it would be good for complications to be actually
problems, and explicitly, not using a reference model link. Though there
might still be a use for pure complications, which might be more procedural
in nature?

Grahame



On Fri, Apr 19, 2013 at 2:32 PM, Heather Leslie 
heather.leslie at oceaninformatics.com wrote:

 I think that many scenarios are possible.

 ** **

 Complications can occur at the time of procedure, can become apparent at a
 distant time and place, or occur at same place and within the same system
 at a later time.

 ** **

 In a complete EHR system there are a number of options. But it is the
 exchange scenario that is trickier.

 ** **

 I think there is probably some advantage in recording something explicit
 about Complication within the Procedure archetype that will point to the
 Problem/Diagnosis for details. And similarly if the Problem/Diagnosis is
 entered first, subsequently pointing to a Procedure ACTION as causal will
 be valuable. The link both ways are useful. But if procedure does not have
 any notion of complication within it and is separated from the rest of the
 EHR in a report or message or research aggregation, there is no indication
 to anyone receiving the data that something untoward may have happened.***
 *

 ** **

 Heather

 ** **

 

 *From:* openEHR-clinical [mailto:
 openehr-clinical-bounces at lists.openehr.org] *On Behalf Of *Sam Heard
 *Sent:* Wednesday, 17 April 2013 8:59 PM
 *To:* For openEHR clinical discussions
 *Subject:* RE: Complications in an event

 ** **

 Ian replied much inline with my views. If it is a serious complication,
 such as pneumonia, it will have its own diagnosis as well, which may even
 contain a following aetiology statement to point back.

 I would not directly embed the notion of a diagnosis in a procedure.

 Cheers Sam

 Dr Sam Heard
 FRACGP, MRCGP, DRCOG, FACHI
 Chairman, Ocean Informatics
 Chairman, openEHR Foundation
 Chairman, NTGPE
 +61417838808
 --

 *From: *Grahame Grieve grahame at healthintersections.com.au
 *Sent: *16/04/2013 9:19 PM
 *To: *For openEHR clinical discussionsopenehr-clinical at lists.openehr.org
 *Subject: *Re: Complications in an event

 Hi Sam 

 ** **

 Procedure does have complications, but it's a simple text / codeableText.
 

 We'd rather use Problem/Diagnosis. So the real question is, does the
 definition 

 of Problem/Diagnosis exclude it's use for for complications of a specific
 event.

 ** **

 Grahame

 ** **

 ** **

 On Tue, Apr 16, 2013 at 6:53 PM, Sam Heard sam.heard at oceaninformatics.com
 wrote:

 Hi All

 It would be good to include Heather here who has been working on operation
 notes. I would have thought that complications within the procedure would
 potentially be useful.

 Cheers, Sam

 -Original Message-
 From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org]
 On Behalf Of Karsten Hilbert
 Sent: Tuesday, 16 April 2013 4:33 PM
 To: openehr-clinical at lists.openehr.org
 Subject: Re: Complications in an event


 On Tue, Apr 16, 2013 at 12:30:17PM +1000, Grahame Grieve wrote:

  If you are recording an event - perhaps a procedure - and you have
  complications to record, are these problem/diagnoses?

 That depends on clinical judgment in each case.

 Karsten
 --
 GPG key ID E4071346 @ gpg-keyserver.de
 E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
 



 

 ** **

 --
 -
 http://www.healthintersections.com.au / grahame at 
 healthintersections.com.au/ +61
 411 867 065 

 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org




-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au/ +61 411 867 065
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130419/6aaf434c/attachment-0001.html

Complications in an event

[Grahame Grieve]

ok thanks

Grahame

On 17/04/2013, at 8:06 AM, Heather Leslie heather.leslie at 
oceaninformatics.com wrote:

 Hi Grahame,
  
 The Complications data element is a DV_Text. So it can capture narrative 
 text. It also has a 0..* Links available as a RM attribute, and so it could 
 be used to Link to a formal recording of a Problem or Diagnosis using the 
 specific Problem/Diagnosis archetype, such that it could be added to a 
 Problem List etc if the clinician thought it warranted it.
  
 From CKM, Link attributes: ?A Link may be made between any two nodes in an 
 EHR. Multiple links can be made and the meaning and type of link defined for 
 each. For example, Links can be used to to associate elements of a Care Plan; 
 to link a supporting Observation to a Diagnosis; or to link a Procedure and 
 the Diagnosis recording a complication.
 PDF  UML
  
 Heather
  
 From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] 
 On Behalf Of Grahame Grieve
 Sent: Tuesday, 16 April 2013 12:30 PM
 To: For openEHR clinical discussions
 Subject: Complications in an event
  
 If you are recording an event - perhaps a procedure - and you have 
 complications to record, are these problem/diagnoses? the existing archetypes 
 simply have complications : text (maybe coded). But aren't these problems, 
 just problems that may only have existed in the context of an event?
 So you could actually use problem/diagnosis?
  
 Grahame
   
  
 -- 
 -
 http://www.healthintersections.com.au / grahame at healthintersections.com.au 
 / +61 411 867 065
 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130417/341a50a0/attachment.html

Complications in an event

[Grahame Grieve]

If you are recording an event - perhaps a procedure - and you have
complications to record, are these problem/diagnoses? the existing
archetypes simply have complications : text (maybe coded). But aren't these
problems, just problems that may only have existed in the context of an
event?
So you could actually use problem/diagnosis?

Grahame


-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au/ +61 411 867 065
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130416/a691454a/attachment.html

Complications in an event

[Grahame Grieve]

Hi Sam

Procedure does have complications, but it's a simple text / codeableText.
We'd rather use Problem/Diagnosis. So the real question is, does the
definition
of Problem/Diagnosis exclude it's use for for complications of a specific
event.

Grahame



On Tue, Apr 16, 2013 at 6:53 PM, Sam Heard
sam.heard at oceaninformatics.comwrote:

 Hi All

 It would be good to include Heather here who has been working on operation
 notes. I would have thought that complications within the procedure would
 potentially be useful.

 Cheers, Sam

 -Original Message-
 From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org]
 On Behalf Of Karsten Hilbert
 Sent: Tuesday, 16 April 2013 4:33 PM
 To: openehr-clinical at lists.openehr.org
 Subject: Re: Complications in an event

 On Tue, Apr 16, 2013 at 12:30:17PM +1000, Grahame Grieve wrote:

  If you are recording an event - perhaps a procedure - and you have
  complications to record, are these problem/diagnoses?

 That depends on clinical judgment in each case.

 Karsten
 --
 GPG key ID E4071346 @ gpg-keyserver.de
 E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org


 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org




-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au/ +61 411 867 065
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130416/e97632dd/attachment.html

The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]

[Grahame Grieve]

Hi Tom

You ask:

 Is there a better meta-architecture available?
When actually the question at hand appears to be: is it even worth having
one?

I don't think that this is a question with a technical answer. It's a
question of what you are trying to achieve. I've written about this here:
http://www.healthintersections.com.au/?p=820

Grahame

On Sunday, April 7, 2013, Thomas Beale wrote:

  On 07/04/2013 00:35, Bert Verhees wrote:

  That's expedient, but it's also a guarantee of non-interoperability.

  As far as I can see, also from my experience, nor OpenEHR, nor MLHIM will be 
 the only datamodel system on the world. Cooperation with other systems will 
 always need a message-format. The same goes for other systems. Mapping will 
 always be (at least partly) done manually.

 The goal, what the customer wants, is not a solution, which dictates him to 
 throw away his system, but he wants connectivity in which his system can 
 participate.



 Hi Bert,

 that's obviously one thing customers want - data interoperability. But -
 what do they want to do with the data? Let's say that want to have a
 managed medication list, or run a query that identifies patients at risk of
 hypertension, or the nursing software wants to graph the heart rate. Then
 they need more - just being able to get the data isn't enough. You have to
 be able to compute with it. That means standardising the meaning somehow.

 Now, each healthcare provider / vendor / solution producer could just
 define their own 'content models'. Like they do today. Or we could try and
 standardise on some of them.

 The openEHR way seems to me the one that can work: because it standardises
 on the archetypes, which are a library of data points and data groups, it
 means that anyone can write their own data set specification (template)
 based on that. So you define what blood pressure looks like once (in the
 archetype) and it gets used in 1000 places, in different ways. But - it's
 guaranteed to be queryable by queries based on the archetype.

 That's the essence of the system - 3 modelling layers:

- reference model - agree on the data
- archetypes - agree on the clinical data points and data groups -
this only needs to be done more or less once; queries are based on these
models
 - templates - define localised / specific data sets using the
archetypes

 We're working on major improvements on the details in ADL 1.5, but I have
 to admit I don't think of trying to change the ground rules. These three
 logical levels are the minimum for data interoperability, content
 standardisation, and local freedom. With specialisation and association
 between models in the archetype and template layers, that's a lot of
 freedom to customise.

 Is there a better meta-architecture available?

 - thomas




-- 
-
http://www.healthintersections.com.au / grahame at healthintersections.com.au
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130413/f56ea4fe/attachment-0001.html

The Truth About XML was: openEHR Subversion = Github move progress [on behalf of Tim Cook]

[Grahame Grieve]

Hi Tom

You ask:

 Is there a better meta-architecture available?
When actually the question at hand appears to be: is it even worth having
one?

I don't think that this is a question with a technical answer. It's a
question of what you are trying to achieve. I've written about this here:
http://www.healthintersections.com.au/?p=820

Grahame

On Sunday, April 7, 2013, Thomas Beale wrote:

  On 07/04/2013 00:35, Bert Verhees wrote:

  That's expedient, but it's also a guarantee of non-interoperability.

  As far as I can see, also from my experience, nor OpenEHR, nor MLHIM will be 
 the only datamodel system on the world. Cooperation with other systems will 
 always need a message-format. The same goes for other systems. Mapping will 
 always be (at least partly) done manually.

 The goal, what the customer wants, is not a solution, which dictates him to 
 throw away his system, but he wants connectivity in which his system can 
 participate.



 Hi Bert,

 that's obviously one thing customers want - data interoperability. But -
 what do they want to do with the data? Let's say that want to have a
 managed medication list, or run a query that identifies patients at risk of
 hypertension, or the nursing software wants to graph the heart rate. Then
 they need more - just being able to get the data isn't enough. You have to
 be able to compute with it. That means standardising the meaning somehow.

 Now, each healthcare provider / vendor / solution producer could just
 define their own 'content models'. Like they do today. Or we could try and
 standardise on some of them.

 The openEHR way seems to me the one that can work: because it standardises
 on the archetypes, which are a library of data points and data groups, it
 means that anyone can write their own data set specification (template)
 based on that. So you define what blood pressure looks like once (in the
 archetype) and it gets used in 1000 places, in different ways. But - it's
 guaranteed to be queryable by queries based on the archetype.

 That's the essence of the system - 3 modelling layers:

- reference model - agree on the data
- archetypes - agree on the clinical data points and data groups -
this only needs to be done more or less once; queries are based on these
models
 - templates - define localised / specific data sets using the
archetypes

 We're working on major improvements on the details in ADL 1.5, but I have
 to admit I don't think of trying to change the ground rules. These three
 logical levels are the minimum for data interoperability, content
 standardisation, and local freedom. With specialisation and association
 between models in the archetype and template layers, that's a lot of
 freedom to customise.

 Is there a better meta-architecture available?

 - thomas




-- 
-
http://www.healthintersections.com.au / grahame at healthintersections.com.au
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130407/e733b54e/attachment-0001.html

An ACTION or INSTRUCTION referencing an AGENT, is it possible?

[Grahame Grieve]

All observations are the result of evaluations of generated data. I
think the difference
is whether the evaluation concerns the data itself, or the
significance of the data
to the patient's treatment.

The problem I have with Evautation vs Observation is that most real
world processes
seamlessly mix both - diagnostic tests are a classic example - some
contain almost
wholly observation, and some contain both, and a few are nearly all evaluation.

Grahame


On Wed, Jun 20, 2012 at 1:17 AM, pablo pazos pazospablo at hotmail.com wrote:
 Hi Jussara,

 I've been struggling with this example from some time now and it would be
 nice to have a clinical oppinion :)

 On imaging tests, the result of the test is not the images itself, but the
 imaging report/radiology report.
 The report is an EVALUATION (there is interpretation here) of an image and
 the image could be seen as an OBSERVATION.

 Should be the report considered as an OBSERVATION or as an EVALUATION?

 Another example is on complex lab tests. Last year I've worked with software
 providers of a private lab and they told me that for some tests they
 manually interpret the results to detect problems and fire alerts. They do
 not have a CDSS to make an automatic process, so the rules where executed
 by lab profesionals, and the result of they interpretation was part of the
 study result.

 I know this is weird but reality is weird :D


 --
 Kind regards,
 Ing. Pablo Pazos Guti?rrez
 LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
 Blog: http://informatica-medica.blogspot.com/
 Twitter: http://twitter.com/ppazos

 From: jussara.macedo at gmail.com

 Subject: Re: An ACTION or INSTRUCTION referencing an AGENT, is it
 possible?
 Date: Sun, 17 Jun 2012 17:56:50 -0300
 To: openehr-clinical at lists.openehr.org


 Hi, guys
 While observation is a sheer report of findings, without any judgement of
 value by the observator, while evaluation is the interpretation of the
 findings made by the interviewer, like a syndrom, a diagnosis. In psychatry
 is very ( or should) very easy to distinguish, mental status examination
 findings are observacional entries, while psychiatric case summary should be
 coded as evaluation ones.



 Sent from my iPad

 On Jun 17, 2012, at 4:39 PM, Diego Bosc? yampeku at gmail.com wrote:

  I would say there is not a common opinion of what an evaluation is.
  Some people agree with your definition, but others say that EVALUATION
  is just 'the generic health care record entry with protocol'
  Eport
  I have seen plenty references to both and I am curious which one is
  the 'correct' one.
 
  2012/6/17 Gustavo Bacelar gbacelar at gmail.com:
  Ation Hi Pablo,
  it is a common mistake to tell apart ACTION and OBSERVATION. The
  Information
  Model document says:
 
  Observations are distinguished from Actions in that Actions are
  interventions whereas Observations record only information relating to
  the
  situation of the patient, not what is done to him/her.
 
  An OBSERVATION can record information about the execution itself, The
  ECG
  recording archetype, for example, includes the device. There are
  other OBSERVATION archetypes that include the Device CLUSTER (e.g.
  Body
  temperature).
 
  Another common mistake I've found in CKM is to classify OBSERVATION as
  EVALUATION (e.g. Tobacco and Alcohol consumption). EVALUATION is an
  Opinion
  considering the Healthcare professional knowledge and OBSERVATION, not
  a
  summary of observations. But it is another topic.
 
  I've also detected many ophthalmologic concepts which are not in the
  CKM and
  I have already done some of them. I'd be glad to contact your student
  (I was
  also a student of your 1st Course) so we can collaborate with each
  other to
  improve the ophthalmologic archetypes in CKM.
 
  Best regards
  --
  Gustavo Bacelar
  MD + MBA + Med Informatics
  gustavobacelar.com
  +351 91 203 2353
  +55 71 8831-2860
  Skype: gustavobacelar
 
 
  ___
  openEHR-clinical mailing list
  openEHR-clinical at lists.openehr.org
 
  http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
 
  ___
  openEHR-clinical mailing list
  openEHR-clinical at lists.openehr.org
 
  http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org

 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org

 ___
 openEHR-clinical mailing list
 openEHR-clinical at lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org



-- 
-
http://www.healthintersections.com.au /
grahame at healthintersections.com.au / +61 411 867 065

Imaging Exam Archetype

[Grahame Grieve]

hi Ian (and others)

I spent some time today working on the imaging exam
archetype with Heather. We had some questions about
the Finding Details section, and Heather thought that
you are responsible for this part. And that part certainly
leaves me confused.

There is a part called Detailed findings. In it, there is

Finding name: Text
  The name of the finding e.g Chest, heart or bones for a Chest x-ray.
Finding: Text
  Brief description, often coded, of an individual finding from an
imaging procedure e.g. '2cm node in left upper lobe'.
Finding description: Text
  A narrative, detailed description of each individual finding

(note for other readers, this version of the archetype is
in preparation, and isn't posted to the CKM)

I don't know what the intent is here. Howe do you differentiate
between these, and know
how to use them consistently?

In fact, I wasn't exactly sure what detailed findings is exactly
meant to be - the
term isn't really defined. I assumed it was for some structured
representation of
the contents of the narrative, presumably to support some kind of synoptic
reporting? I'd add at least a Finding Value : ANY so that proper synoptic
reports would be possible.

Heather and I thought that some examples might help have a productive
discussion.
This is some of the things I thought might be useful to say in a coded way
using snomed + values

LMP: [value in months]
size of (uterus, placenta, foetus): [value in mm]
[Snomed Concept 84138006: Collapse of vertebra]
246120007: Nodule size = [20mm]
422005008: Ferucarbotran (product)

That'll probably do to start us off. If no one claims reponsibility or
defends this
model, I'll suggest that we have just code | value following the classic HL7
model. It's certainly got it's problems, but at least they are well understood,
and the openEHR model would match the HL7 v2/v3 models of the same

Grahame

p.s. I tried to code exactly 2cm node in left upper lobe, but snomed
isn't vague
  in those ways

New requirements from endoscopy (was Re: GUI-directives/hints again (Was: Developing usable GUIs))

[Grahame Grieve]

 semantic and presentation information.
 So we propose to delegate the semantics part to modelling side and use
 another GUI directive called ?hideChildren? (which actually we have also
 defined before but not used. This directive can then be used for core and
 non-core concepts.



 We think this might best be denoted in the RM; either at CLUSTER or ITEM
 classes. Something like null flavours but not quite the same. Or perhaps a
 dedicated new class?? That?s up to the discussions.

 well moving null flavours to ITEM (meaning CLUSTER and ELEMENT both get it)
 would not be that hard to do - it has no negative impact on anything. But we
 have not done any general semantic analysis on this idea...



 2) We also saw that some clinical findings can exist alone; i.e. without
 further qualification or depicting anatomical sites. Example is haemorrhoids
 where anatomical site is implied and it can just be reported as
 ?haemorrhoids were observed? (can be qualified as internal external or even
 a grade but the point is it can exist on its own). But when you talk about a
 tumour you need further description? i.e. site, type, grade etc. It is not a
 valid clinical expression to say ?tumour was present? in an endoscopy report
 (yes context is important, in some other contexts this expression may well
 be valid). This indeed was also denoted in openSDE with a GUI directive
 called ?selection requires further description?.



 To depict standalone findings during archetype design setting the
 cardinality of CLUSTER to 0..* or 0..n can be used. But currently we cannot
 set cardinality to 0 for CLUSTER: this is not allowed according to AOM
 (although in openEhrV1 it's possible to have CLUSTER's with 0 ITEM's as long
 as it isn't validated by the RmValidator, this isn't considered a desirable
 usage).

 but you can't record any data in a CLUSTER with no children. If the CLUSTER
 is named (i.e. has at-code) for 'haemorrhoids' the implication is that
 something is going to be said about this. The function of this name/code
 here is as a name, not as a value. Some ways of doing this would be:

 ELEMENT [haemorrhoids]; value = present

 or

 CLUSTER [haemorrhoids];
 ??? CLUSTER -- more complex description of haemorrhoids
 ??? ??? ELEMENT
 ??? ELEMENT
 ??? etc

 or

 CLUSTER [features present];
 ??? ELEMENT [observed feature]; value = haemorrhoids
 ??? ELEMENT [observed feature]; value = something else
 ??? etc



 The real issue is a bit more tricky and has to do with core semantics: it
 doesn?t make sense to depict a finding as absent or unknown when qualified
 by certain attributes.



 One example is: ?Three polyps were observed at ascending colon? there is no
 point in saying ?Three polyps were absent at ...?



 But this is a perfectly valid (and quite frequently used) expression in
 endoscopy reporting: ?Villous polyps were absent at ascending colon? (here
 villous is an attribute for type of polyp).



 Another invalid expression: ?3 cm long stenosis was been absent...?

 ok, so absence / negation is a common requirement in endoscopy...



 So it looks like some qualifiers may change the existence of core concepts ?
 so perhaps we need some means to tag them during modelling. It looks like
 these are ?physical? properties and not ?man-made? concepts.

 I think you mean that the possibility of reporting absence (when it can make
 sense) depends on the morphological feature?

 - thomas




 ___
 openEHR-technical mailing list
 openEHR-technical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical





-- 
Grahame Grieve, CTO
A: Suite 8a / 17 Burgundy St, Heidelberg VIC 3083
P: + 61 3 9450 2230
M: + 61 411 867 065
F: + 61 3 92450 2299
E: grahame at kestral.com.au
W: http://www.kestral.com.au

Demographics archetypes

[Grahame Grieve]

Hi Ian

Well, if the review is not completed, that'd be why I don't see feedback.
Broader sign off is indeed a good goal

Grahame


On Tue, Jun 8, 2010 at 6:49 PM, Ian McNicoll
Ian.McNicoll at oceaninformatics.com wrote:
 Hi Grahame,
 In my efforts to drum up broader?demographic archetype?review input, I
 neglected to thank those, yourself included, who have already made very
 valuable suggested changes and corrections. Your particular expertise in
 this field is very much appreciated. I will liaise with Sergio re the
 current status of responses to your comments - you should definitely have
 received feedback when the review round was completed.
 The current reviews are those to which you have already contributed. My main
 concern was to try and get a broader 'sign-off' (or otherwise) that these
 are now fit-for-purpose for a range of developers and other interested
 parties.
 Regards,
 Ian
 Dr Ian McNicoll
 office / fax ?+44(0)141 560 4657
 mobile +44 (0)775 209 7859
 skype ianmcnicoll
 ian.mcnicoll at oceaninformatics.com
 ian at mcmi.co.uk

 Clinical Analyst ?Ocean Informatics openEHR Archetype Editorial Group
 Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland



 On 8 June 2010 02:00, Grahame Grieve grahame at kestral.com.au wrote:

 Hi Ian

 The archetypes had been open to comment once before, and I commented at
 length
 at that time. (or are these different archetypes?)

 Maybe it's just because I can't use CKM well, but I cannot find any
 responses
 to my comments. Looking at the archetypes, I can't tell whether my
 comments
 have caused any change (A quick survey suggests not)

 Most of my comments reflected requirements brought forward by a number
 of national programs through the ISO 21090 process, so I think they'll
 eventually come up.

 Grahame


 On Tue, Jun 8, 2010 at 10:28 AM, Ian McNicoll
 Ian.McNicoll at oceaninformatics.com wrote:
  Hi,
 
  We have had a couple of Demographics model archetypes up for review on
  CKM
  for some time but with very little input from the community at large.
  This
  may reflect low demand for these archetypes, but there seemed to be
  quite a
  lot of interest prior to the reviews being opened. I appreciate everyone
  is
  pushed for time and it may be that the lack of comment reflects the
  overall
  high quality of the archetypes that Sergio and his colleagues have
  developed. Certainly we have been making use of them in a number of
  different local and national projects with a high degree of success, so
  perhaps the lack of feedback simply reflects that they are not causing
  upset
  or controversy. However, it would be really helpful if anyone who is
  using
  or who expects to use these archetypes could have a look and, if nothing
  else, just sign them off as being acceptable.
 
  The ethos of openEHR is about developing shared content models, we can
  only
  do that if we get input from those with an interest in these models -
  the
  more early input we get, the better and more stable will be the
  resulting
  archetypes.
 
  We plan to keep the review rounds open for another 2 weeks and then
  close
  them off with a view to publication.
 
  Any contributions would be very much appreciated.
 
  The links are
 
  Address :
  http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.484
 
  Person Name:
  http://www.openehr.org/knowledge/OKM.html#showArchetype_1013.1.477
 
  ?Regards,
 
  Ian
 
  Dr Ian McNicoll
  office / fax ?+44(0)141 560 4657
  mobile +44 (0)775 209 7859
  skype ianmcnicoll
  ian.mcnicoll at oceaninformatics.com
  ian at mcmi.co.uk
 
  Clinical Analyst ?Ocean Informatics openEHR Archetype Editorial Group
  Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health
  Scotland
 
 
  ___
  openEHR-clinical mailing list
  openEHR-clinical at openehr.org
  http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
 



 --
 Grahame Grieve, CTO
 A: Suite 8a / 17 Burgundy St, Heidelberg VIC 3083
 P: + 61 3 9450 2230
 M: + 61 411 460 568
 F: + 61 3 92450 2299
 E: grahame at kestral.com.au
 W: http://www.kestral.com.au

 ___
 openEHR-clinical mailing list
 openEHR-clinical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical





-- 
Grahame Grieve, CTO
A: Suite 8a / 17 Burgundy St, Heidelberg VIC 3083
P: + 61 3 9450 2230
M: + 61 411 460 568
F: + 61 3 92450 2299
E: grahame at kestral.com.au
W: http://www.kestral.com.au

??? DV_CODEDQUANTITY

[Grahame Grieve]

Ordinals are not just about order. That's certainly a primary use, but for some
specific ordinal scales, specific operations are defined that give
(quasi) meaningful
results when performed upon the numbers. There's no general case, and
additionally,
I think that many of the specific defined operations fail any sort of
rigor test at all.
But never-the-less, they are defined and used in clinical contexts.
That's an additional
reason why the ordinal equivalent in ISO 21090 has a real number for
value, not an
integer. And for this reason, openEHR should probably have a real too.
But I don't
see a path from here to there, as it were

Grahame


On Wed, Apr 21, 2010 at 7:49 PM, Thomas Beale
thomas.beale at oceaninformatics.com wrote:

 Hi Mark,

 the openEHR model of 'ordinals' (right or not) is that each ordinal value is
 an association of an integer with a symbol (which could be words, but also
 anything else like '++'). The numbers are used to make the ordering
 computable - in fact this is the definition of the 'ordinal' concept in
 openEHR - that there is order without otherwise any proper scaled notion of
 magnitude.

 This data type (DV_ORDINAL) is used in at least two ways (wrongly or
 rightly):

 to model scales of symbols, such as 'none', '+', '++', '+++' and so on
 (maybe pain, reaction, urinalysis analytes), where there are otherwise no
 numerics built into the published scale - i.e. someone had to invent them
 when creating archetypes or other openEHR artefacts
 to model scales whose values are primarily expressed as numerics and whose
 'symbols' are just words
 to model scales of numbers like Apgar and Barthel, where the primary
 expression of 'value' is numeric, and the numbers are meant to be added up,
 and the 'symbol' is in fact a term, i.e. explanatory phrase

 doing this has the desired effect in all cases of establishing computable
 ordering between adjacent members (since computers don't understand that
 '++' is somehow 'less than' '+++'). But it is clear that there are
 downsides:

 in the first case above, it is us (i.e. archetype modellers) adding
 arbitrary numbers to make the scale of values computable
 in the second and third cases, there is no obvious reason why real numbers
 should not be chosen, especially in the last case above, since the values
 might be carefully chosen to make the subsequent additions have a certain
 effect.

 At the very least it seems that we need is the ability to use real numbers
 as well as just integers. Maybe there is more to it - I certainly don't have
 a good enough feel for the use of these kinds of scales in medicine, nor
 their implied semantics. With respect to literature, I have to admit we did
 not find anything much on ordinal scales, although we tried to stick to
 well-known notions of accuracy, precision, units etc in the design of the
 main quantitative data types in openEHR (also proper mathematical notions
 which lead to meaningful operations, e.g. + and - being defined on true
 'amounts' but not on dates). If you know of any literature on this topic of
 scale design, I am sure it would be helpful here.

 - thomas

 On 21/04/2010 09:12, Mark Leaning wrote:

 I am hesitant to enter this discussion, but here goes.



 An assessment scale which assigns a numeric score as well as a symbol/term
 is not an ordinal scale. The symbols do in fact comprise an ordinal scale
 (?very low?  ?low? etc). However the numerics provide something else ?
 usually to be added up with other scores. The designers of such scales are
 bound to validate the composite numeric scores (cf SF36).



 What you then have is ordinal symbol + real number. If the scale designer
 needs to use decimals, that is their choice.



 It might be worth looking at the measurement theory literature.



 Cheers

 Mark



 Mark S Leaning PhD

 ___
 openEHR-clinical mailing list
 openEHR-clinical at openehr.org
 http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical

Adverse Reaction archetype - review round initiated

[Grahame Grieve]

Hi Heather

 

I have to admit that the difference between gathering more business
requirements and collating existing

research is clearer in theory than in practice

 

I will comment in the review

 

Grahame

 

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Heather Leslie
Sent: Monday, July 06, 2009 5:09 PM
To: For openEHR clinical discussions
Subject: Re: Adverse Reaction archetype - review round initiated

 

Hi Grahame,

The current scope for Adverse Reaction is the initial ideal for every
archetype at creation - a maximal dataset for a universal usecase.   

So the current intent of use of the archetype includes within a report,
within DSS, a clinical summary and any other way of utilising it.  The
archetype can then be constrained to make it 'fit for purpose' through
context/scenario-appropriate templates.

The current Adverse Reaction archetype is a 'straw man' model that needs
considerable refining and enhancing - no doubt about it.  It represents the
thinking of a few people, based on lots of experience and only one reference
noted.  The purpose of this review is not to gather yet more business
requirements but to collate the existing research and thinking done by many
learned and expert organisations and national programs into a practical and
pragmatic model that we can take forward as the basis for sharing common
things about adverse reactions.  

As you quite rightly point out, the metadata needs quite a bit of
enhancement. The review process should identify any missing data elements,
and usecases not currently anticipated.  The metadata will be improved to
support all of this. 

Look forward to seeing your comments through the review.  You can comment on
each individual data element or metadata item, plus the completeness and/or
any missing elements, general issues with regard to the design of this
archetype, and other resources that should be considered for this archetype.

Kind regards

Heather

On 6/07/2009 9:15 AM, Grahame Grieve wrote: 

hi Sam

 

happy to do it on CKM, but the interface didn't suggest itself as suitable
for this kind of scoping

discussion

 

Grahame

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Sam Heard
Sent: Monday, July 06, 2009 8:37 AM
To: 'For openEHR clinical discussions'
Subject: RE: Adverse Reaction archetype - review round initiated

 

Grahame,

 

Do it on CKM - not on the list! Then the ideas will not be lost. The
proposal certainly covers more than you have noted but would not in itself
support a report. This would be a template. 

 

Cheers, Sam

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Grahame Grieve
Sent: Sunday, 5 July 2009 1:52 PM
To: 'For openEHR clinical discussions'
Subject: RE: Adverse Reaction archetype - review round initiated

 

hi

 

I'd like to start by asking about the scope of this archetype. 

Is the intent to report about a condition of an adverse reaction?

or a concern about? or just a report of a possible one? 

 

Is it a high level clinical summary, or is it supposed to be good

enough to support DSS?

 

I have considerable interest in this archetype: as well as being 

involved with this model through NEHTA and HL7, my daughter 

is highly allergic to tree nuts, but (a little unusually), not peanuts 

as well.

 

It seems to me that the current archetype is only good for a 

gross point report of a single episode of apparent adverse 

reaction. If this is all it's supposed to be, I won't have much to say,

but if it's supposed to be good for more than that..

 

I'd like the archetype to comment on this. Recording the 

presence of a harmful or undesirable response to an agent 

or substance including food, as determined by the 

clinician - excluding poisoning and abnormal use is 

ambiguous concerning these questions.





 

Grahame

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Heather Leslie
Sent: Friday, July 03, 2009 3:26 PM
To: For openEHR clinical discussions; For openEHR technical discussions
Subject: Adverse Reaction archetype - review round initiated

 

Dear Colleagues,

A review round for the Adverse Reaction archetype was initiated today.  This
is a significant archetype that requires careful and considered
collaboration and I would like to ensure that we have the best team
reviewing the specs as we can.

Current reviewers comprise the openEHR Archetype Editorial Group plus
existing adopters of the archetype, however we welcome broader expertise
from the broader openEHR community.

If you, or one of your colleagues, would like to participate in the review,
please log in and adopt the archetype.  Instructions and diagrams for
adopting are found at
http://www.openehr.org/wiki/display/healthmod/Adopt+an+archetype

All adoptors will be included in the ongoing

Adverse Reaction archetype - review round initiated

[Grahame Grieve]

hi Sam

 

happy to do it on CKM, but the interface didn't suggest itself as suitable
for this kind of scoping

discussion

 

Grahame

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Sam Heard
Sent: Monday, July 06, 2009 8:37 AM
To: 'For openEHR clinical discussions'
Subject: RE: Adverse Reaction archetype - review round initiated

 

Grahame,

 

Do it on CKM - not on the list! Then the ideas will not be lost. The
proposal certainly covers more than you have noted but would not in itself
support a report. This would be a template. 

 

Cheers, Sam

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Grahame Grieve
Sent: Sunday, 5 July 2009 1:52 PM
To: 'For openEHR clinical discussions'
Subject: RE: Adverse Reaction archetype - review round initiated

 

hi

 

I'd like to start by asking about the scope of this archetype. 

Is the intent to report about a condition of an adverse reaction?

or a concern about? or just a report of a possible one? 

 

Is it a high level clinical summary, or is it supposed to be good

enough to support DSS?

 

I have considerable interest in this archetype: as well as being 

involved with this model through NEHTA and HL7, my daughter 

is highly allergic to tree nuts, but (a little unusually), not peanuts 

as well.

 

It seems to me that the current archetype is only good for a 

gross point report of a single episode of apparent adverse 

reaction. If this is all it's supposed to be, I won't have much to say,

but if it's supposed to be good for more than that..

 

I'd like the archetype to comment on this. Recording the 

presence of a harmful or undesirable response to an agent 

or substance including food, as determined by the 

clinician - excluding poisoning and abnormal use is 

ambiguous concerning these questions.

 

Grahame

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Heather Leslie
Sent: Friday, July 03, 2009 3:26 PM
To: For openEHR clinical discussions; For openEHR technical discussions
Subject: Adverse Reaction archetype - review round initiated

 

Dear Colleagues,

A review round for the Adverse Reaction archetype was initiated today.  This
is a significant archetype that requires careful and considered
collaboration and I would like to ensure that we have the best team
reviewing the specs as we can.

Current reviewers comprise the openEHR Archetype Editorial Group plus
existing adopters of the archetype, however we welcome broader expertise
from the broader openEHR community.

If you, or one of your colleagues, would like to participate in the review,
please log in and adopt the archetype.  Instructions and diagrams for
adopting are found at
http://www.openehr.org/wiki/display/healthmod/Adopt+an+archetype

All adoptors will be included in the ongoing review process.

[If you are a registered CKM user, and/or subscribe to multiple openEHR
lists, you may have received this notification several times - my
apologies;-)]

Kind Regards

Heather Leslie
(Editor) 

-- 

Dr Heather Leslie
MBBS FRACGP FACHI
Director of Clinical Modelling
Ocean Informatics http://www.oceaninformatics.com/ 
Phone (Aust) +61 (0)418 966 670
Skype - heatherleslie 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20090706/1fd1af65/attachment.html

Adverse Reaction archetype - review round initiated

[Grahame Grieve]

hi

 

I'd like to start by asking about the scope of this archetype. 

Is the intent to report about a condition of an adverse reaction?

or a concern about? or just a report of a possible one? 

 

Is it a high level clinical summary, or is it supposed to be good

enough to support DSS?

 

I have considerable interest in this archetype: as well as being 

involved with this model through NEHTA and HL7, my daughter 

is highly allergic to tree nuts, but (a little unusually), not peanuts 

as well.

 

It seems to me that the current archetype is only good for a 

gross point report of a single episode of apparent adverse 

reaction. If this is all it's supposed to be, I won't have much to say,

but if it's supposed to be good for more than that..

 

I'd like the archetype to comment on this. Recording the 

presence of a harmful or undesirable response to an agent 

or substance including food, as determined by the 

clinician - excluding poisoning and abnormal use is 

ambiguous concerning these questions.

 

Grahame

 

From: openehr-clinical-boun...@openehr.org
[mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Heather Leslie
Sent: Friday, July 03, 2009 3:26 PM
To: For openEHR clinical discussions; For openEHR technical discussions
Subject: Adverse Reaction archetype - review round initiated

 

Dear Colleagues,

A review round for the Adverse Reaction archetype was initiated today.  This
is a significant archetype that requires careful and considered
collaboration and I would like to ensure that we have the best team
reviewing the specs as we can.

Current reviewers comprise the openEHR Archetype Editorial Group plus
existing adopters of the archetype, however we welcome broader expertise
from the broader openEHR community.

If you, or one of your colleagues, would like to participate in the review,
please log in and adopt the archetype.  Instructions and diagrams for
adopting are found at
http://www.openehr.org/wiki/display/healthmod/Adopt+an+archetype

All adoptors will be included in the ongoing review process.

[If you are a registered CKM user, and/or subscribe to multiple openEHR
lists, you may have received this notification several times - my
apologies;-)]

Kind Regards

Heather Leslie
(Editor) 

-- 

Dr Heather Leslie
MBBS FRACGP FACHI
Director of Clinical Modelling
Ocean Informatics http://www.oceaninformatics.com/ 
Phone (Aust) +61 (0)418 966 670
Skype - heatherleslie 

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20090705/b7899aa7/attachment.html

Insight into the choices to be made in standards for the electronic exchange of health record information

[Grahame Grieve]

 Again it's not my document and not my decission and if you had taken  
 the time to read my mail properly you could have known that.
 Luckely the Istanbul meeting is in 2 weeks so there is plenty of time  
 to come up with an alternative document in which al of your brilliant  
 analyses are put togehter. I really encourage you to do so.

Which Istanbul meeting? The combined ISO/CEN meeting that starts
on Sunday?

Grahame

Terminology releases

[Grahame Grieve]

 Sorry, I did not explain well.
 Some concepts in SNOMED cannot be described by appropriate Japanese,
 because we do not have such concepts in our native culture.
 eg. Japanese 'Sushi' has no conceptual matching to the other countries
 foods
 However, we can describe such concept as 'sour rice ball with raw fish'
 euphemistically.

I don't think that sushi is a snomed concept. So what specific
concepts cannot be described by appropriate Japanese?

I find it a surprising notion actually. I certainly expect that there
are snomed concepts that are not easy to describe in direct Japanese,
but what is not possible?

Grahame

Microsoft/NHS common health interface and openEHR datatypes

[Grahame Grieve]

 I don't think (a) is a property of the EPL license itself. But
 it is certainly exactly how the Eclipse Foundation vets code
 that will be posted to the official eclipse cvs.
   
 I'm not trying to be critical as such - its just that Rong found code 
 that we would be prevented from using if we converted the license to EPL.

yeah, this is not easy. (though as I said, it's not just converting
to EPL, it's subjecting to the full eclipse processes)

 In the end, I don't think I am really convinced by the need to have a 
 special license for the Eclipse project; there are clearly some license 
 that the code can't use, but it seems unrealistic to me to try and make 
 it one. But prepared to be shown the light


well, I look at it this way: eclipse is a reliable proposition for everyone:
no surprises. I doubt that we (kestral) could use the openEHR java kernel 
corporately
because of GPL issues. I do not have the skills or the time to find out exactly
what I can and cannot do without inadvertantly subjecting my corporate stuff to
GPL. But if I use eclipse code (not just EPL), I know that appropriately skilled
and highly motivated people have done this for me.

So for a project to become eclipse, and to actually mean putting the code
up on eclipse, it has to jump these hurdles. Why do this?

pros:
  - will increase target market of the code substantially. however, while in 
tools
market, the corporate benefits of eclipse in this regard are well 
recognised,
I don't think there's the same brand penetration in the healthcare sector 
regarding
Eclipse sanitising your code for you
  - will allow a full engagement between multiple communities, in particular, 
the
community that is growing around eclipse

cons:
  - have to jump the hurdle. It can be quite high and painful. The more mature 
the
project, the more painful, (and possibly the pros are reduced here too)


If I was you, I wouldn't be making the change right now either. I think that the
correlation of forces will change in the future, and then I will ask you to
re-evaluate.

In the meantime, we are pursuing alternate pathways that will enable community
collaboration with more flexibility about how the price is paid and when. There
should be public announcements soon.

Grahame

CEN meeting and data types

[Grahame Grieve]

hey Sam

I'll bite ;-)

  but the openEHR data types are ready for
  archetypes and the cluster element (leaf node) architecture.

it you want, we can go round and round on semantic issues. Always
a pleasure ;-). But is there anything specific that makes
you think that it would be inappropriate or unwise to use the
iso datatypes in the document with 13606? (so not including
general issues)

Grahame

Sam Heard wrote:
 Dear All
 
 I have been at the CEN working group meetings representing Standards 
 Australia. 
 It is clear to me that CEN needs to take on the openEHR data types in order 
 to 
 progress quickly. The ISO data types are likely to be appropriate for the HL7 
 environment and will map to openEHR - but the openEHR data types are ready 
 for 
 archetypes and the cluster element (leaf node) architecture.
 
 You can have a look at the ISO data type proposal likely to come through HL7 
 soon at:
 
 http://informatics.mayo.edu/wiki/index.php/ISO_Datatypes
 
 user name: wiki
 
 password: wikiwiki
 
 
 It will be helpful to make your views known on this list.
 
 Cheers, Sam
 -- o
___
openEHR-clinical mailing list
openEHR-clinical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical