[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Belgian EMR structuration
From: |
Karsten Hilbert |
Subject: |
[Gnumed-devel] Belgian EMR structuration |
Date: |
Sat, 31 Jul 2004 09:27:11 +0200 |
User-agent: |
Mutt/1.3.22.1i |
> >See http://hherb.com/cgi-bin/twiki/view/Gnumed/CountryNotes
> I was thinking to put anchor links at the top of the page each time anyone
> adds a
> country (or location within country).
Sounds very reasonable.
> Maybe
> what I am describing overlaps with "localization" but "Country Notes" seemed
> clearer.
We could cleanly separate the two issues, eg. on the
CountryNotes page keep country related *functional* type
requirements/spec links etc. (eg *what* to localize) while on
the Localization page keep developer oriented info on *how* to
localize that What.
> Most of what Dominique posted seems seems not country-specific - rather, a
> set of
> design and functional requirements that are being presented.
Perhaps country-specific in that those are (mandatory?) design
requirement for a particular country ?
> Notable however was the content in one of the links abstracted below, in
> which they
> discuss health issues, encounters, episodes. I found very helpful their term
> "subcontacts" referring, within any one encounter/contact, to the bits that
> pertain
> to any one issue in a multi-issue contact. I did not quite understand how
> they
> differentiate a contact "which may or may not have an encounter", maybe have
> to read
> it over again.
If I understand correctly: Contact = when a Health Agent (doc)
does something to the EMR. Subcontact = the part thereof
related to a single "episode of care" eg one problem eg one
Health Approach eg one Health Care Element (the latter similar
in nature to our clin_root_item). Only if the patient is
actually involved in the Contact (eg. by phone or in person)
does it turn into an Encounter. We just subsume the former
under "Chart review" where review stands for "accessed and
read part of it for whatever reason" not necessarily re-view
as in re-analysis.
> Early in the document they suggest that while in SOAP the P is traditionally
> "Plan"
> they propose it be used for Procedure or Treatment. In their examples, P is
> used to
> contain the procedures/treatments that are
> done/prescribed/initiated/requested.
The literature suggests a couple of acronyms:
SnOcAP
AXIS
HOAP
SOAP
> Definitions of the concepts as used in the Belgian quality labelling process
> for
^^^^^^^^^^^^^^^^^^^^^^^^^
One of the main problems I have with such things. They don't
commit themselves to generically tagging different parts of the
health process but rather try to attach business meaning to the
classification right from the start. This is pretty much the
same thing why surrogate keys have advantages over natural keys
in database design and why many terminologies/ coding systems
have failed to deliver what they were intended for.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346