"Heath Frankel" <heath.frankel at frankelinformatics.com> wrote:
I have to agree to a high degree with Heath here (exception is on the HL7 harmonisation process). I have been working on developing archetypes since original CEN work for ICNP / Mose / Nursys, and follow up work in templates within HL7 work. Further several Dutch projects under HL7 v3 umbrella for which I met with Heath. I believe that the clinical expression of variables, values, datatype, cardinalities, relationships between variables (e.g. in scales) is the most demanding part of all work. Using any formalism, (more HL7 v3 people are looking at the archetype approach for that, so the discussion on ?best? can be considered for the past), is important to bridge clinical to technical worlds. In this formalism we need to be able to define discrete items (clinically: one observation or one measure, e.g. weight). Then we must be able to have archetypes that combine clinically natural combinations of discrete variables (blood pressure: systolic, diastolic, cuff size, position). Such examples can be globally standardized, at least to the level where the units are referenced appropriately, e.g. kg weight versus Lbs. The we must have archetype to represent clinical constructs, such as assessment scales / instruments. These have usually a clinimetric / psychometric research based set of characteristic, assuming a 100% correct technical representation. This is doable with archetyping, e.g. the apgar score and Barthel index examples. To me this is in specifying clinical content with a formalism is such a way that these small pieces can be selected upon choice to be included in different formats. Each format can be seen as a template: a logical, clinical grouping or collection of archetypes (selection of 1, 3, 5 or 5.000.000 depending on purpose) meeting a specific purpose. Purposes in the real world are: database design, screen design, HER / OpenEHR style, but also a technical artefact is an HL7 v3 message, or given discussion the CCR style of material. In other words: archetypes will be globally definable, or at least referred to, where the template specifies many different implement able ?things? that will vary to purpose. The flexibility Heath mentions is absolutely required. E..g. a discharge summary after delivery will have similar components (template level) compared to discharge summary after stroke care, (e.g. blood pressure template, weight), but also differ (first has Apgar score archetype, second has Barthel index). The template thus must hold place for 1-n scales to be includable upon choice of clinicians and depending the actual technical implementation. For me encounter and medication list are definitely not archetypes: they differ too much in each circumstance, they are templates that will hold several to many archetypes. The problem list within HL7 has been addressed and is now part of the set of messages useful for referral and discharge. That set is going for 3 year stable DSTU once ANSI has dealt with the bureaucracy. The allergy and intolerance is still a problem, not due to R-MIM modelling, but clinical and national registry etc level discussion on business needs. So the first step: sorting out the clinical content, is blocking the speedy consensus. So with respect to Heath comments on this: no agreement, it will work. >Andrew, > >> > Actually sections are purely organisational only, they do >> not change >> > the semantics of the entries inside them. >> >> I guess I disagree about the possibility (or usefulness) of >> defining globally recognised archetypes as you go further up >> the tree (towards organising archetypes like encounter, >> medication list etc). This is why I would see a CCR as a >> composition archetype, with the specific sections and details >> as per the CCR spec. I don't see the possibility (or value) >> of defining the CCR as a template of some generic 'discharge' >> archetype. > >Well, we will have to agree to disagree, but ultimately it is the clinicians >that will make the decision, not us techos. > >However, from my past experience working on consultancies to develop >national discharge summary and referral templates that a flexible modular >approach is necessary to cater for the various situations where discharge >summaries and referrals are used. This means there are likely to more than >one template for discharge summaries and referrals and that a single "one >fits all" CCR like template will not be sufficient. This is especially the >case for the CCR as it is a summary document and experience shows that some >circumstances require more detail in certain areas are whole new sections of >data. > >> > of the Care Provision domain for many years). It has taken >> > 2 years >> > (and it continues) to agree on the RIM structures required to >> > semantically define a Problem List and Allergy. We do not >> have this >> > problem in openEHR as the semantics of the concept are >> declared by the >> > definition of an archetype and >> >> So why do you believe it will be possible to get global >> agreement on the definition of the Problem List and Allergy archetype? > >It is not the set of data elements that need to be collected that has taken >so long to determine (these are usually already well documented in clinical >literature) but the requirement to extend the RIM vocabulary (through a long >and tedious Harmonization process) and agree on particular combinations of >RIM classes and attributes to be used to map its semantics to those data >elements. > >Heath > >_______________________________________________ >openEHR-clinical mailing list >openEHR-clinical at openehr.org >http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > _______________________________________________ openEHR-clinical mailing list openEHR-clinical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
