Very pragmatic, but ... If dealing with the 20% of 'abnormal' problems later, means completely redesigning and reimplementing a solution, then your pragmatic approach may not be the best.
Designing and building a national or international EHR-based healthcare system is like getting someone to the moon - it is a complex and expensive exercise. Better to pre-empt the abnormal situations and build something that you hope will succeed, than to build a rocket that you know will fail. eric ---- On Wed, 18 Dec 2002, Gerard Freriks wrote: > Hi, > > Yes nice, but ... > > Dealing with 80% of all 'normal' problems that can be encountered is > difficult enough. > 'Give me a solution and I will find the problems, the scenario's that will > brake the solution' > > The 20% of 'abnormal' problems can (and will have to be) dealt with later. > > Gerard > > > On 2002-12-17 14:24, "Sam Heard" <sam.heard at bigpond.com> wrote: > > > > > Matthew > > > > Great scenario's > > > >> 1. If prenatal diagnosis is being done by chorionic villus sampling > >> (CVS) in a twin pregnancy (which does happen) then it is the placenta > >> - or rather the placentas - which are sampled. Each placenta has a > >> DNA genotype matching that of the fetus attached to it (ie not the > >> mother) as the placenta is an extension of the fetus. If however the > >> fetus is an extension of the mother, then are we really saying we > >> like the idea that the placentas may have to appear as multiple > >> "temporary" organs of the mother, which are different in every > >> pregnancy, and which never share her total genotype? A likely outcome > >> would be selective termination of one twin (the affected one, on the > >> basis of a molecular finding and either a makable or a confidently > >> predictable clinical diagnosis) leaving the unaffected one to go to > >> term. Thus a part of the mother is diagnosed clinically and > >> molecularly, findings which are important for the mother later on, in > >> that they'll trigger appropriate care next time around, but which > >> *must not* be confused with her own clinical diagnoses or test > >> results. > > > > This example is a very good one - it shows that there is a need to identify > > the fetus over and above its relationship with the mother. I have suggested > > that we use a local label for this - could be LOCAL:Twin1_2002. - the > > relationship for the information is FETUS. The important thing here is that > > we have the idea of subject of care - a unique identifier (or self) and the > > relationship. > > > > The sampling is the taking of a histological sample of a body part - the > > subject is the FETUS. There will be a procedure record, a sample and a > > histological report - all with the fetus as the subject of care for the > > data - in a composition that is part of the mothers EHR. It may be copied to > > the child's EHR in the future - I have thought about the transform required > > to do this and it should be relatively easy if the relationship of the two > > records is stated first. > > > >> 2. Bone marrow transplantation, where it may be necessary to > >> distinguish that the post-transplant patient may still have a > >> haemoglobin variant, but a different one to the one they were treated > >> for, and accordingly no disorder to go with it, but will still be > >> genetically as they were before the treatment in every other organ. > >> Also the donor was most probably selected from the same family, so > >> confidentiality may be slightly different...? > > > > Interesting - who is the subject of care then? I guess this will be deduced > > from the data - I do not think that we can say the origins of all the states > > in a person that arise following a donation - at times it may be ambiguous > > (graft v host). > > > > We have considered 'donor' to be the relationship - but the person may have > > a relationship with the person apart from this? I do not think that the > > subject of care needs to be the donor then - it can be the family member as > > it is known who they are. Interesting! > > > >> It seems to me that we can either organise our concepts to make this > >> kind of record easier and more obvious, or we can begin to inbuild > >> problems for later on (eg if the fetus is part of the mother, having > >> to explain to all our knowledge agents that this might not extend to > >> genotypes, or if it does, then by chance rather than biological > >> imperative etc...). In the event of one of two fetuses being > >> affected, and one pregnancy being terminated, what is the result in > >> the record to indicate the original number of conceptions, the fact > >> that a genetic risk actually produced a fetus with a prospective > >> problem, and the DNA and other data originated in the process of the > >> testing of the CVS sample? It would be wrong, I feel, to treat the > >> fetus' diagnosis as one of the mother, as confusion here could lead > >> to all kinds of erroneous conclusions (one fetus had sickle cell -> > >> mother - who is actually just a carrier - has sickle cell...?). > > > > I do believe that we have this covered - the donor example is a bit of a > > mind bender but I think the subject of care and relationship provides the > > solution. > > > > COmments? > > > > Cheers, Sam > > ____________________________________________ > > Dr Sam Heard > > Ocean Informatics, openEHR > > Co-Chair, EHR-SIG, HL7 > > Chair EHR IT-14-2, Standards Australia > > Hon. Senior Research Fellow, UCL, London > > > > 105 Rapid Creek Rd > > Rapid Creek NT 0810 > > > > Ph: +61 417 838 808 > > > > sam.heard at bigpond.com > > > > www.openEHR.org > > www.HL7.org > > __________________________________________ > > > > - > > If you have any questions about using this list, > > please send a message to d.lloyd at openehr.org > > -- <private> -- > Gerard Freriks, arts > Huigsloterdijk 378 > 2158 LR Buitenkaag > The Netherlands > > +31 252 544896 > +31 654 792800 > > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
