I might need Adam to help with the specifics but from memory, since we implemented a problem oriented care plan, we had a set of goals that may be relevant for a specific problem, the targets relevant to a goal, the type of data representation of the target (e.g text, single value, range, less than/greater than) and the kind of activities (instructions) that are relevant to achieving the goal target. Can't remember if there is a reference to the observation value that would be used to evaluate the target variance.
As you can see this is more than clinical model semantics, but with this we are able to drive the app to capture this data and populate the generic goal archetype data. Some of this could probably be represented using GDL, but I haven't explored this yet. Regards Heath > On 25 Jun 2014, at 7:53 pm, "Ian McNicoll" <ian at mcmi.co.uk> wrote: > > Hi Heath, > > That is very interesting. Can you give an example of the kind of > metadata you are storing externally? I don't see the problem per-se > with having term-driven models but perhaps that is because a UK > perspective is always a bit more comfortable with this approach, but I > also understand how that also has a number of limitations once you > move away from labellling the goal and any specific targets. > > I modelled a few Goals/targets in the SemanticHealthNet Heart failure > summary and using SNOMEDCT seemed to work reasonably well but I > suspect your requirements were a bit more complex. > > http://www.openehr.org/ckm/#showTemplate_1013.26.14 > > Ian > > Ian > >> On 25 June 2014 10:29, Heath Frankel <heath.frankel at oceaninformatics.com> >> wrote: >> Hi All, >> Based on our experience working with goals and targets in our Care Planning >> system in Australia, the use of specialised Goals is not viable option from >> an implementation perspective. The specialisation I am talking about is a >> little different to what has been discussed so far as we were using >> templates to constrain the generic goal archetype for a specific type of >> goal. Therefore, it really relates to the alternative CLUSTER approach >> also. This worked fine from a modelling perspective but when it came to >> implementing it in an app, it was a nightmare. We had to have specific code >> to handle each type of goal (template) but we wanted a solution where we >> could easily add a new type of goal without needing to do any further >> coding. This may be a result of the way we build our apps since after many >> years developing real clinical apps deployed in dozens of hospitals, we have >> chosen not to use a form generated approach as we do not believe this >> provides the end user with a great user experience or enable enough control >> over the application workflows. Perhaps those of you that are smarter have >> been able to achieve this but I don't think the models should make any >> assumptions about how one should develop their Application. >> >> What we ended up doing is implementing a generic approach to recording goals >> and targets that was metadata driven. The metadata is maintained separately >> from the goal archetype and drives the way the application presents and >> captures data about each type of goal (OK, perhaps we do have a little bit >> of form generation, but it is separate from the archetype and only were it >> makes sense). You might say that this metadata should be in the archetype >> for all to use, but we come back to the usual argument that archetypes is >> just a model for what can be recorded about a concept, not the business >> rules specific to a particular use case, application, project or >> jurisdiction. >> >> As someone suggested, I think this is where GDL starts to kick in and we >> should stop trying to overload the functionality of archetypes with all this >> business rule (guideline) semantics. >> >> Regards >> >> Heath >> >> -----Original Message----- >> From: openEHR-clinical [mailto:openehr-clinical-bounces at >> lists.openehr.org] On Behalf Of Ian McNicoll >> Sent: Tuesday, 24 June 2014 5:34 PM >> To: For openEHR clinical discussions >> Subject: Re: Link between goals and other clinical concepts >> >> Hi Pablo, >> >> ** Yes, creating CLUSTERs for all the stuff than can be measured and we can >> potentially define goals is a. a big job, b. will change a lot of currently >> stable archetypes. ** >> >> Agree but the ongoing maintenance burden is even worse. >> >> Specialisation is certainly a possibility. The problem is that the potential >> targets are almost limitless and it would be difficult to know how many >> common specialisations to build. >> >> The Heart failure template gives several real world examples, including a >> mix of quantifiable and non-quantifiable goals. I have modelled the >> non-quantifiable examples as a goal without a target e.g Goal = "Minimise >> heart failure related symptoms". >> >> I like the idea of a modelling guideline document and of identifying >> exceptions that cannot be handled by the current Goal archetype. >> >> Ian >> >> I like the idea of a modelling gui >> >>> On 24 June 2014 01:28, pablo pazos <pazospablo at hotmail.com> wrote: >>> Hi Ian, >>> >>> Yes, creating CLUSTERs for all the stuff than can be measured and we >>> can potentially define goals is a. a big job, b. will change a lot of >>> currently stable archetypes. >>> >>> In this scenario, maybe the second option is to specialize the goal >>> archetype for each specific measurement. This is a. less work compared >>> to creating CLUSTERs, and b. but will create an implicit dependency to >>> the measurement archetype (if that changes the goal archetype might >>> need to be revised), but I think that is not going to happen too much. >>> >>> About the quantifiable goals, I'm biased by my experience. As I said, >>> I would like to propose the creation of a use case list to see which >>> kinds of goals are more frequent and how different implementations are >>> modeling this. >>> >>> For not quantifiable goals, I don't know if we need a correlation >>> between the archetype of the specification of the goal and the >>> archetype of the measurement. So maybe this discussion only applies to >>> quantifiable goals. >>> For other goals like "low sodium diet" that can't be evaluated >>> directly (the evaluation would be boolean: yes I'm following the diet, >>> no I'm not following), but an indirectly evaluation can be made on a >>> factor that depends on the diet like the BP: if the low sodium diet is >>> followed by the user, the doctor can measure if the BP decreases. So >>> instead of evaluating against the goal, this is evaluating other >>> factors that depends on the goal and the compliance of that goal by >>> the patient. To evaluate this kind of stuff, I agree with Hugh: we >>> need a higher level on modeling, maybe something related to GDL. >>> >>> I think the most important things here are: >>> >>> a) find real use cases to be sure we can model them, >>> b) differentiate quantifiable and not quantifiable goals, >>> c) classify those goals in terms of "they can be modeled in openEHR" >>> or "they need a higher level of modeling" (maybe by specializing the >>> goal archetype, maybe with terminology, etc.). >>> d) create a small modeling guideline just for goals and measurements, >>> maybe just for "quantifiable" and "can be modeled with openEHR" goals. >>> >>> What do you think? >>> >>> >>> -- >>> Kind regards, >>> Eng. Pablo Pazos Guti?rrez >>> http://cabolabs.com >>> >>>> From: ian at mcmi.co.uk >>>> Date: Mon, 23 Jun 2014 11:13:13 +0100 >>> >>>> Subject: Re: Link between goals and other clinical concepts >>>> To: openehr-clinical at lists.openehr.org >>>> >>>> Hi Pablo, >>>> I have copied Heather's response below. >>>> >>>> I will stick with my assertion that changing the basic modelling >>>> approach to create CLUSTER or ELEMENT archetypes for every >>>> concievable 'targetable' datavalue will create a completely >>>> unmanagable set of models. If the intention is to model data values + >>>> units + precision in a contextless fashion, it would be far more >>>> efficient to do this with a terminology like LOINC. >>>> >>>> I also don't agree that every goal or even target has or needs a >>>> quantifiable reduction. If you can forgive my stereotyping, that is >>>> very much an 'engineering' view of the world, which translates pretty >>>> poorly into clinical practice ;-) >>>> >>>> Of course we do sometimes need to specify actual targets but broad >>>> goals can be just as important, and often the only thing that can be >>>> asserted. >>>> >>>> Having said that, I can see the argument for 're-using' the systolic >>>> blood pressure unit/precision/range constraints from an Observation >>>> archetype in the context of a goal / target. I think that can be >>>> acheived by treating the source archetype as a reference >>>> document/node without the need for a major and very complex/costly >>>> use of cluster and element archetypes by using tooling to point to >>>> the target archetype and importing the quantity constraints at >>>> specialisation or templating time. >>>> >>>> There is a broader issue here about abstraction. We can always get a >>>> more sophisticated about our re-use of generic patterns, in ways that >>>> seem elegant and efficient, but in doing so we often leave behind a >>>> significant segment of our clinical stakeholders , and indeed dev. >>>> community who are largely outsiders to this strange world. If you ask >>>> us to re-work every OBSERVATION archetype to use an ELEMENT or >>>> CLUSTER to represent each 'key ' data element. you will force the >>>> creation of at least 3 artefacts instead of 1 - The Observation >>>> container, 1 cluster/element for each data point, and a templated >>>> archetype so that we can get clinicians to look at 'blood pressure' >>>> in a clinically meaningful representation. >>>> >>>> Ian >>>> >>>> Ian >>>> >>>> >>>> >>>> ============================================ >>>> i Heather! >>>> >>>> [PP:] Yes, I was evaluating the goal archetype. Great, now I get what >>>> the "Target archetype node" is for. >>>> About that I have a question, what's the role of the "Target >>>> measurement"? My understanding was that's the value set for the goal >>>> (e.g. target body weight), >>>> >>>> [HVL:] Agreed. Perhaps we should refine the name/description to make >>>> that clearer. >>>> >>>> not the measurement to be evaluated against the goal (e.g. current >>>> body weight). >>>> If that value is the measurement, where should the value for the goal >>>> be set? Or the idea is not to set a value like quantity but set a >>>> text in "Target". >>>> My question was focused on the relationship between the value set for >>>> the target goal and the archetype used to record the measurements to >>>> be compared with the value of the goal. Because the goal and the >>>> measurements should comply the same constraints (magnitude, units, >>>> etc) >>>> >>>> [HVL:] Understood . That is what I was referring to with my comment >>>> ?correlation with magnitude and unit constraints would be nice to >>>> have, but is not currently easy to achieve.? We would currently do >>>> that manually in the template. Alternatively we could specialise the >>>> goal archetype for each measurement, but that has lots of overheads >>>> as well. >>>> >>>> If we were to look at changing the modelling patterns to allow for a >>>> common CLUSTER to be used within both the measurement OBSERVATION and >>>> the EVALUATION.goal then we could achieve what you asked for. In the >>>> current ADL 1.4 world that would be an enormous modelling overhead as >>>> then no measurement model is standalone and ready to go but needs to >>>> be combined with others in order to be used in every modelling >>>> scenario. >>>> It is not clear that the requirements for goal justify the changed >>>> modelling pattern scenario. The value and clarity of the standalone >>>> OBSERVATIONs is huge. >>>> >>>> Also, what about when you have a goal for the BP and you need to >>>> specify a value for systolic and diastolic? Should I create two >>>> instances of the goal? (One for systolic and one for diastolic). >>>> >>>> [HVL:] Depends on what you are trying to achieve. You could do it the >>>> way you describe, and then reaching each goal can be assessed >>>> independently. Or if you want to reduce the BP as a whole, you could >>>> set a goal of ?Reduce BP? and have two targets, one for Systolic and >>>> the other for Diastolic >>>> >>>>> On 23 June 2014 03:48, pablo pazos <pazospablo at hotmail.com> wrote: >>>>> Hi Ian / Thomas / Heather, >>>>> >>>>> That's weird, I didn't received Heathers' response email :) >>>>> >>>>> I think the idea of reusing CLUSTERs is cleaner and simpler than my >>>>> idea of specializing the goal archetype. What's nice about that is >>>>> if we add a slot in the current Body Weight archetype to a CLUSTER >>>>> to hold the measurement record, the paths in the B.W. archetype may >>>>> not change. >>>>> >>>>> About Thomas proposal, I see a lot of overlapping between the >>>>> Epistemic Status and OBSERVATIONs / INSTRUCTIONs, and also with the >>>>> INSTRUCTION state-machine states. So, I'm not 100% sure if we need >>>>> add that, maybe if we find some use cases that can't be modeled >>>>> otherwise, that would help. >>>>> >>>>> About using intervals for the measurements, I think that's >>>>> overkill. A better idea would be just to reuse the constraints for >>>>> units, magnitude and precision (if the target is DV_QUANTITY). So, >>>>> if the archetype for the measurement defines constraints for those >>>>> data fields, in the goal archetype I would set references to those >>>>> constraints of each limit of the interval defined as goal. I don't >>>>> really know if that reference can be done via SLOTs because the >>>>> reference is not only to an archetype, is to a specific/fine >>>>> grained part of that archetype, so we might need the path in the SLOT. >>>>> >>>>> Can this be done in ADL 1.4? Is planned to add this kind of >>>>> fine-grained SLOTs to ADL 1.5? >>>>> >>>>> About goals like "Reduce BP", I think goals like that have implicit >>>>> numeric semantics, and what we need are numeric values to be >>>>> compared with measurements. When we specify "reduce" or "increase", >>>>> the next questions is how much? So we need a number. Also, if we >>>>> set an x..y interval for a goal and the current measurement is z, >>>>> if z > y, the goal is to "reduce", but if z < x, the goal is to >>>>> "increase" (that's the implicit semantics I mentioned above). I >>>>> fact to have "reduce/increase" goals was a requirement in a current >>>>> project and when I mentioned the implicit semantics they removed >>>>> that requirement, now we have just intervals and first measurement >>>>> to now if the goal is to increase or reduce. >>>>> >>>>> In general, and because this goal/measurement is really a pattern >>>>> all over healthcare, I would like to find / define a "best >>>>> practice" of modeling this using openEHR (maybe just a guide for >>>>> ADL 1.4 but for ADL 1.5 we might propose some model changes for the >>>>> IM or AOM to support this pattern as it support the HISTORY pattern >>>>> and the INSTRUCTION/ACTION pattern to track state changes). >>>>> >>>>> What do you think about specifying how we all model the >>>>> goal/measurement today to create a pool of real use cases, and then >>>>> propose some openEHR friendly way(s) of modeling it? (as you notice >>>>> I'm trying to avoid Hugh's proposal to use a higher level model to >>>>> link goal and measurements :) >>>>> >>>>> Personally, I have a couple of experiences with this, is not much >>>>> but is >>>>> something: one was a complete system design to manage patients with >>>>> chronic pain and the other a system to manage celiac patients. Both >>>>> with goals and result tracking. >>>>> >>>>> >>>>> -- >>>>> Kind regards, >>>>> Eng. Pablo Pazos Guti?rrez >>>>> http://cabolabs.com >>>>> >>>>>> From: ian.mcnicoll at oceaninformatics.com >>>>>> Date: Sun, 22 Jun 2014 13:41:47 +0100 >>>>>> Subject: Re: Link between goals and other clinical concepts >>>>>> To: openehr-clinical at lists.openehr.org >>>>> >>>>>> >>>>>> Hi Pablo, >>>>>> >>>>>> You can see an example of the Goal archetype in-use via the SHN >>>>>> Heart Failure template at >>>>>> >>>>>> http://www.openehr.org/ckm/#showTemplate_1013.26.14 >>>>>> >>>>>> This was my interpretation, which I think aligns with Heather's >>>>>> but others may vary! >>>>>> >>>>>> To answer Mark's point, I think the archetpye does support >>>>>> defining a range of values via the Interval datatypes. >>>>>> >>>>>> As Thomas has said, this is the subject of some discussion in the >>>>>> CIMI world. Although some sort of epistemic status flag/mood code >>>>>> seems attractive, it works very badly for Goal/Target. It is >>>>>> pretty obvious that the contents of an archetype for Target Blood >>>>>> pressure is very different for that ob the measurement itself. The >>>>>> only part of the highly complex blood pressure measurement >>>>>> archetype which has any value in the blood pressure target >>>>>> archetype are the systolic, diastolic and perhaps MAP datapoints >>>>>> and even at that level the original observation data point is a >>>>>> single value , whereas the target is likely to be an interval. To >>>>>> make an epistemic flag work we would need to model the original >>>>>> measurement as an interval, which is entirely possible technically >>>>>> but requires us to further constrain the measurement archetype at >>>>>> template level to make it useable. >>>>>> >>>>>> As Heather has pointed out, it might be possible to re-model every >>>>>> key data point as an individual cluster or even element archetype >>>>>> but that imposes a very significant burden on the modelling work, >>>>>> particularly clinical review, where we would again effectively >>>>>> have to re-create the existing blood pressure measurement >>>>>> archetype as a template with all of the additional constraints and >>>>>> aggregation. I don't think the CIMI group have really taken this >>>>>> on-board. >>>>>> >>>>>> In a sense, at least for the 'Target/Goal' scenario, all that we >>>>>> want to do is to re-use the datatype and units from the original >>>>>> 'measurement' archetype. We probably need to use different SNOMED >>>>>> bindings and convert the data type to its INTERVAL equivalent. So >>>>>> I would question whether there is any real value in re-using the >>>>>> original constraint pattern. Arguably the only attribute which is >>>>>> actually copied intact is the unit. >>>>>> >>>>>> I think it might actually be more sensible to use the current >>>>>> approach where an existing archetype node is pointed to for >>>>>> information but that this is then used by tools to replicate/adapt >>>>>> the original constraints. i.e this is re-use via copy/paste/edit >>>>>> rather than direct re-use/inheritance.aggregation. >>>>>> >>>>>> I suppose it all comes down to the value of direct re-use. At >>>>>> least for the Target/Goal scenario, I suspect the overhead of >>>>>> doing this far outweighs any benefit, and I think may be another >>>>>> example of informaticians trying to construct ontologically pure >>>>>> and elegant solutions which actually just get in the way of >>>>>> implementation. >>>>>> >>>>>> The eHealth record is fundamentally anti-pattern. >>>>>> >>>>>> Ian >>>>>> >>>>>> Ian >>>>>> >>>>>> On 20 June 2014 06:32, Heather Leslie >>>>>> <heather.leslie at oceaninformatics.com> wrote: >>>>>>> Hi Pablo, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Comments inline >>>>>>> >>>>>>> >>>>>>> >>>>>>> Heather >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: openEHR-clinical >>>>>>> [mailto:openehr-clinical-bounces at lists.openehr.org] >>>>>>> On Behalf Of pablo pazos >>>>>>> Sent: Friday, 20 June 2014 10:09 AM >>>>>>> To: openEHR Clinical >>>>>>> >>>>>>> >>>>>>> Subject: RE: Link between goals and other clinical concepts >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Heather! >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes, I was evaluating the goal archetype. Great, now I get what >>>>>>> the "Target archetype node" is for. >>>>>>> >>>>>>> >>>>>>> >>>>>>> About that I have a question, what's the role of the "Target >>>>>>> measurement"? >>>>>>> My understanding was that's the value set for the goal (e.g. >>>>>>> target body weight), >>>>>>> >>>>>>> [HVL:] Agreed. Perhaps we should refine the name/description to >>>>>>> make that clearer. >>>>>>> >>>>>>> >>>>>>> >>>>>>> not the measurement to be evaluated against the goal (e.g. >>>>>>> current body weight). >>>>>>> >>>>>>> If that value is the measurement, where should the value for the >>>>>>> goal be set? Or the idea is not to set a value like quantity but >>>>>>> set a text in "Target". >>>>>>> >>>>>>> >>>>>>> >>>>>>> My question was focused on the relationship between the value >>>>>>> set for the target goal and the archetype used to record the >>>>>>> measurements to be compared with the value of the goal. Because >>>>>>> the goal and the measurements should comply the same constraints >>>>>>> (magnitude, units, etc) >>>>>>> >>>>>>> [HVL:] Understood . That is what I was referring to with my >>>>>>> comment ?correlation with magnitude and unit constraints would >>>>>>> be nice to have, but is not currently easy to achieve.? We would >>>>>>> currently do that manually in the template. Alternatively we >>>>>>> could specialise the goal archetype for each measurement, but >>>>>>> that has lots of overheads as well. >>>>>>> >>>>>>> >>>>>>> >>>>>>> If we were to look at changing the modelling patterns to allow >>>>>>> for a common CLUSTER to be used within both the measurement >>>>>>> OBSERVATION and the EVALUATION.goal then we could achieve what >>>>>>> you asked for. In the current ADL >>>>>>> 1.4 world that would be an enormous modelling overhead as then >>>>>>> no measurement model is standalone and ready to go but needs to >>>>>>> be combined with others in order to be used in every modelling >>>>>>> scenario. >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is not clear that the requirements for goal justify the >>>>>>> changed modelling pattern scenario. The value and clarity of the >>>>>>> standalone OBSERVATIONs is huge. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also, what about when you have a goal for the BP and you need to >>>>>>> specify a value for systolic and diastolic? Should I create two >>>>>>> instances of the goal? >>>>>>> (One for systolic and one for diastolic). >>>>>>> >>>>>>> [HVL:] Depends on what you are trying to achieve. You could do >>>>>>> it the way you describe, and then reaching each goal can be >>>>>>> assessed independently. >>>>>>> Or >>>>>>> if you want to reduce the BP as a whole, you could set a goal of >>>>>>> ?Reduce BP? >>>>>>> and have two targets, one for Systolic and the other for >>>>>>> Diastolic >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Kind regards, >>>>>>> Eng. Pablo Pazos Guti?rrez >>>>>>> http://cabolabs.com >>>>>>> >>>>>>> ________________________________ >>>>>>> >>>>>>> From: heather.leslie at oceaninformatics.com >>>>>>> To: openehr-clinical at lists.openehr.org >>>>>>> Subject: RE: Link between goals and other clinical concepts >>>>>>> Date: Wed, 18 Jun 2014 03:13:09 +0000 >>>>>>> >>>>>>> Hi Pablo, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is it safe to assume that you?ve seen the current archetype for Goal? >>>>>>> It >>>>>>> is >>>>>>> here: http://www.openehr.org/ckm/#showArchetype_1013.1.124 >>>>>>> >>>>>>> >>>>>>> >>>>>>> In it we have a data element that specifically identifies the >>>>>>> archetype and path of the specific node that should be used to >>>>>>> capture the actual measurement, eg the weight or height or >>>>>>> systolic blood pressure. >>>>>>> >>>>>>> >>>>>>> >>>>>>> This combination of the EVALUATION.goal archetype with various >>>>>>> target OBSERVATIONs for recording the actual data is being used >>>>>>> in implementations in Australia as part of a personalised care >>>>>>> plan, as Hugh has indicated. >>>>>>> The >>>>>>> correlation with magnitude and unit constraints would be nice to >>>>>>> have, but is not currently easy to achieve. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> >>>>>>> >>>>>>> >>>>>>> Heather >>>>>>> >>>>>>> >>>>>>> >>>>>>> From: openEHR-clinical >>>>>>> [mailto:openehr-clinical-bounces at lists.openehr.org] >>>>>>> On Behalf Of pablo pazos >>>>>>> Sent: Saturday, 14 June 2014 5:21 AM >>>>>>> To: openEHR Clinical >>>>>>> Subject: Link between goals and other clinical concepts >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi, if I want to establish a goal for body weight, I think >>>>>>> there's a need of linking the goal concept with the body weight >>>>>>> concept, but the body weight archetype is for measuring the >>>>>>> weight not to specify a goal for it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I understand the difference between a goal (what you want to >>>>>>> achieve, fixed >>>>>>> value) and the measures (to control your progress and compare >>>>>>> with the goal, variable value through time). >>>>>>> >>>>>>> >>>>>>> >>>>>>> Also, I think the target measurement from the goal archetype >>>>>>> will depend on the specific concept I'm creating a goal for >>>>>>> (body weight), I mean the magnitude and units constraints should >>>>>>> be inherited someway from the concept I'm measuring (body >>>>>>> weight) into the goal archetype. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Does anyone has an idea of how will be a good way of modeling a >>>>>>> goal related to another concept like weight or BP? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Kind regards, >>>>>>> Eng. Pablo Pazos Guti?rrez >>>>>>> http://cabolabs.com >>>>>>> >>>>>>> >>>>>>> _______________________________________________ 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 >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dr Ian McNicoll >>>>>> office +44 (0)1536 414 994 >>>>>> fax +44 (0)1536 516317 >>>>>> mobile +44 (0)775 209 7859 >>>>>> skype ianmcnicoll >>>>>> ian.mcnicoll at oceaninformatics.com >>>>>> >>>>>> Clinical Modelling Consultant, Ocean Informatics, UK Director >>>>>> openEHR Foundation www.openehr.org/knowledge Honorary Senior >>>>>> Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland >>>>>> BCS Primary Health Care www.phcsg.org >>>>>> >>>>>> _______________________________________________ >>>>>> openEHR-clinical mailing list >>>>>> openEHR-clinical at lists.openehr.org >>>>>> >>>>>> >>>>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.o >>>>>> penehr.org >>>>> >>>>> _______________________________________________ >>>>> openEHR-clinical mailing list >>>>> openEHR-clinical at lists.openehr.org >>>>> >>>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.op >>>>> enehr.org >>>> >>>> >>>> >>>> -- >>>> Dr Ian McNicoll >>>> office / fax +44(0)141 560 4657 >>>> mobile +44 (0)775 209 7859 >>>> skype ianmcnicoll >>>> ian at freshehr.com >>>> >>>> Clinical modelling consultant freshEHR Director openEHR Foundation >>>> Honorary Senior Research Associate, CHIME, UCL BCS Primary Health >>>> Care www.phcsg.org >>>> >>>> _______________________________________________ >>>> openEHR-clinical mailing list >>>> openEHR-clinical at lists.openehr.org >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.open >>>> ehr.org >>> >>> _______________________________________________ >>> openEHR-clinical mailing list >>> openEHR-clinical at lists.openehr.org >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.opene >>> hr.org >> >> >> >> -- >> Dr Ian McNicoll >> office / fax +44(0)141 560 4657 >> mobile +44 (0)775 209 7859 >> skype ianmcnicoll >> ian at freshehr.com >> >> Clinical modelling consultant freshEHR >> Director openEHR Foundation >> Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care >> www.phcsg.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 > > > > -- > Dr Ian McNicoll > office / fax +44(0)141 560 4657 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian at freshehr.com > > Clinical modelling consultant freshEHR > Director openEHR Foundation > Honorary Senior Research Associate, CHIME, UCL > BCS Primary Health Care www.phcsg.org > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
