Yes - that's all correct except that without archetypes you can't say anything except that this is a piece of text etc. You really need archetypes because the database schema really means nothing unless you describe it with archetypes. The interesting thing about openEHR is that actually neither the reference model or the archetype model contain anything that is really health specific. It could be deployed basically as is, in other areas such as finance.
__________________________________ Dr Hugh Leslie MBBS, Dip. Obs. RACOG, FRACGP, FACHI M: 0404 033 767 E: [EMAIL PROTECTED] > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Richard Hosking > Sent: Tuesday, 3 January 2006 11:15 PM > To: General Practice Computing Group Talk > Subject: Re: GP Requirements - was [GPCG_TALK] Re: The Dreaming > > So let me get this right - the backend DB schema represents > the reference model, which is relatively simple. > Data is stored along with the ID of the archetype that it was > validated against. > The archetype engine, when it is coded, sits between DB and > GUI/client (or is part of DB ultimately) and validates data > in both directions. > > I guess the first step (if one wanted to follow OpenEHR) > would be to use your reference model in the DB schema, even > if one did not use or have an archetype engine. > Will this work by itself? > > The archetype engine will have to be closely linked to the > GUI for data validation and display (or even *be* the GUI) > > Forgive all these questions :) > > R > > Hugh Leslie wrote: > > >It is hard to get your head around but fun! :) > > > >The current way to design systems is to try to understand > the whole of > >clinical medicine and design a database schema to match it so that > >every piece of data has a matching table or set of fields. > This leads > >to ever expanding and inflexible schemas that have to be added to or > >changed whenever our clinical understanding grows or > changes. It means > >that we as clinicians have to try to describe clinical concepts to > >programmers so that they can build systems that work. > > > >openEHR separates the data model from the semantic model. > Lets look at > >some xml of a serialised openEHR composition - (serialised > using the > >.net kernel that is very functional now) > > > ><Item xmlns="openEHR/v1/Composition" > >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="section" > >archetype_id="openEHR-EHR-SECTION.summary.v1" rm_version="1.0"> > > <NodeID>at0000</NodeID> > > <Item xmlns="openEHR/v1/Composition" > >xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="evaluation" > >archetype_id="openEHR-EHR-EVALUATION.problem-diagnosis-histol > ogical.v1" > >rm_version="1.0" local_impl_IsSelf="true"> > > <NodeID>at0000.1.1</NodeID> > > <Name xsi:type="dv_coded_text"> > > <value>Histological diagnosis > as defined > >by a clinician</value> > > <DefiningCode> > > > <CodeString>at0000.1.1</CodeString> > > <TerminologyID> > > <ID>local</ID> > > </TerminologyID> > > </DefiningCode> > > </Name> > > <Data xsi:type="item_tree" node_id="at0001"> > > <Item xsi:type="element" > >node_id="at0002.1.1"> > > <Name xsi:type="dv_text"> > > <value>Histological > >diagnosis</value> > > </Name> > > <Value > xsi:type="dv_coded_text"> > > <value>Seminoma, > >testicle</value> > > <DefiningCode> > > > ><CodeString>314567</CodeString> > > <TerminologyID> > > > <ID>SNOMED-CT</ID> > > </TerminologyID> > > </DefiningCode> > > </Value> > > </Item> <!-- at0002.1.1 --> > > </Data> > > </Item> > > </Item> > > > >This is a subset of data from a sample histology report and is > >describing the diagnosis. What you are looking at is data > stored using > >the reference model. If you look at the data you will see that it is > >stamped with the archetype id all the way through and all > the nodes are > >describing very generic structures. When retrieving this data, the > >kernel will match it with the the archetype to validate it. Any > >archetyped data can be saved with the same set of reference model > >classes. So you don't need to keep changing the database > schema to add > >new clinical concepts, just the archetypes. > > > >Its worth reading through the openEHR documentation as while > there is a > >lot of it, it makes the whole concept clearer. > > > >Regards Hugh > > > >-----Original Message----- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] > >On Behalf Of Richard Hosking > >Sent: Tuesday, 3 January 2006 9:39 PM > >To: General Practice Computing Group Talk > >Subject: Re: GP Requirements - was [GPCG_TALK] Re: The Dreaming > > > >I still struggle with this stuff - isnt an archetype describing > >constraints on the data- ie type, bounds etc? Shouldnt this be coded > >into the DB? If not where? > > > >Richard > > > >Hugh Leslie wrote: > > > > > > > >>An openEHR database schema doesn't contain ANY archetypes - > The data > >>reflects the openEHR reference model, not the archetype > model. If you > >>have to hard code archetypes in a schema then you have not gained > >>anything at all. The archetypes just describe what the data means. > >> > >> > >> > >> > >> > >> > >_______________________________________________ > >Gpcg_talk mailing list > >[email protected] > >http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > >_______________________________________________ > >Gpcg_talk mailing list > >[email protected] > >http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > > > > > > > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
