2011/4/17 Sebastian Hilbert
<address@hidden>
Am Sonntag, 17. April 2011, 03:08:51 schrieb Rogerio Luz Coelho:
The database table will have to be done by Karsten.
I could have a try at implementing some browser widget.
I am not sure about the complexity yet. There is more then meets the eye.
There is storing one or more codes and there is assigning one or more codes.
Assining involves picking it from some code browser. You could help by
thinking about a workflow and maybe find existing ideas and collect what you
like or dislike.
The hard part will be to support multiple coding systems per se, multiple
codes per health issue, multiple versions within a coding system and multiple
languages per one coding system.
So we have at least
OPS for procedures
ICD 9 and ICD 10
we have ICD 10 WHO and e.g. ICD 10 GM (Germany)
and we have ICD-10 GM 2009 and ICD-10 2010 and ICD-10 2011
It takes an database wizard to get this done.
Then there is the code browser part. One could/should start simple and go from
there. Initially we could preselect the coding system per doctor. this has
nothing to do with the storing part in the database. This is about getting the
code you are looking for from a list of codes.
Later this code browser could/should support multiple coding systems and
return matches from more then one source. Even later it could find related
codes.
Don´t see why this is so ... let every locale download the code it neeeds, this is a first atempt at a new feature.
This brings up the issue of the source. How is the source stored for easy
access ?
ICD10 GM 2010 is provide as ASCII or XML or pdf and a few more. There is at
least one commercial product which makes use of the XML directly. Other option
would be to import the sources (e.g. ICD9, 10) into special database tables
and retrieve them from there.
Ok is this possible? Worthwhile?
How about we first provide a code_icd10 storage in the DB ... then we make it available to the user, we make it visible for those who could/should be able to see this info (see below).
My idea would be something like this:
1) At the end of the current SOAP plugin there would be a separator called "Code" (or ICD)
2) That separator would have a input field/frasewheel (if the source of ICD is too dificult to manage, for now, just a input field that would accept 1 or 2 ICDs per Encounter - it would be the job of the physician to find the correct ICD - via web, or hardcopy or his memory, we would not rely on GNUmed for this step right now) and a box(es?) to click if the ICD is meant to be confidencial (to everybody but the doctor that made the Encounter / viewed by all the practice doctors / viewed by everybody in the practice ... etc) which could be set as a configuration also I assume ... for practice wide installations.
3) When in the journal ou tree view the ICD would show besides the name of the encounter (for those who were authorized to see it)
4) I REALLY think 1-3 codes for an Encounter are more than enough, if not we can always open another encounter.
Rogerio