> The point of the demonstration was that you could make snomed easier for
> clinicians to use by creating these subsets ie medication route. These
> subsets to be useful would need to be defined at a jurisdictional level or
> higher so that everyone can use the same one. This allows for a change in
> the query to be distributed easily and updates to the coding system to be
> distributed in the same way. To make this work, it will be necessary to
> have some centrally controlled repository that the URL or other identifier
> can match the query to. Analogous to archetype identifiers I guess. It may
> be possible to include term set queries in the archetype if some universal
> query language is available.
Just thinking long term, just say some archetype was defined for
some little used data entry. The archetype (which includes a URL
term binding) is put into the clinical system. Some data matching
the archetype is entered - the system checks that the terminology codes
for allowed data match those returned in the URL and all is good. 10
years down the
track, someone goes to do the same thing. Given Australian government
departments barely keep their names for more than a few years, what are
the chances the URL is still working? If it is a local reference, what are the
chances the machines still have the same IP addresses or names?
Can the clinical system still rely on the term codes it cached 10 years
ago?
I think having URL's in the archetype definition mixes the 'configuration' of
the system with the definition. I guess I would like to see some sort of
query language in this space so that one could say
<"at0004"> = <
<"snomed"> = <all 'route of medication' where refset('australia')>
<"icd-10"> = <12312-23>
>
or something similar in the actual ADL. Each terminology/classification
would probably need its own language and I have no idea how to
define any of this, so I guess I'm not really being much help, but I just wanted
to see what the general thinking was about this problem.
Andrew
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
