This is as good a summary as any. To go a bit further: some particular instances of EHR content will clash with competing message definitions relating to the same topic - the latter manually defined. Further, the EHR structures can be used to machine-generate message defintions for all the EHR content, not just particular ones that were chosen by message design teams - and in particular including messages with numerous slight variations from ones that may have been manually modelled. This is the situation in which we find ourselves today. We obviously need to deal with existing messages, e.g. HL7v2 and EDIFACT, but hand-building messages is not an appropriate strategy for the future. It creates the situation where the definition of the 'line packet' now dictates to systems what their data should be, and in an inflexible , non reusable way.
- thomas Andrew Patterson wrote: > >From a non-clinical background I would make these statements - not > sure if they are correct or particularly relevant but I'll throw it > out there and see if anyone agrees. > > (1) > A message standard is a commitment between two parties > to 'understand' a set of data at a defined level. This is why > maximal data modelling at a message level doesn't really make > sense - noone can write computer systems that 'understand' > all the data in a maximal model. Complete semantic understanding > of the content of the message is a _requirement_ for health messaging > systems (I may not totally understand every field of a message but > I at least have to have an agreement between the two parties as > to which fields I am allowed to ignore!) > > (2) > An EHR standard is a commitment to faithfully record data > meeting a defined level of structure. Maximal data modelling > makes sense because the EHR is committing just to the storage > of the data, and to allow its retrieval in a standardised way. The > EHR doesn't necessarily have to 'understand' the data, merely > has to be able to retrieve and present it. Any semantic understanding > that the EHR achieves through archetypes etc is > a bonus. > > > (1) and (2) are very different use cases - there may be value in > sharing common artifacts or bases for the two (ala the template > definitions from Ocean seem to me to be a mechanism to > allow the definition of (1) but in a way that reliably and easily > transforms into something suitable for (2)) > > Andrew > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > > -- *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> * *
