Sophie

Sophie

distrib > Fedora > 18 > i386 > by-pkgid > 761c4f285d3afa353219933c4b5717e0 > files > 49

gnumed-doc-1.2.9-1.fc18.noarch.rpm

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en_US" lang="en_US">
<head>
	<title> GmManualDocumentManagementConcepts &lt; Gnumed &lt; Foswiki</title>
		  
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <meta name="robots" content="noindex" /> <link rel="alternate" type="application/rss+xml" title="RSS Feed" href="WebRss.html" />
	<link rel="icon" href="../rsrc/System/ProjectLogos/favicon.ico" type="image/x-icon" /> <link rel="shortcut icon" href="../rsrc/System/ProjectLogos/favicon.ico" type="image/x-icon" />
	<link rel="alternate" href="http://wiki.gnumed.de/bin/edit/Gnumed/GmManualDocumentManagementConcepts?t=1362919416" type="application/x-wiki" title="edit GmManualDocumentManagementConcepts" />
	<meta name="description" content="GmManualDocumentManagementConcepts" />
	 <!--[if IE]></base><![endif]-->
	
	<style type="text/css" media="all">
@import url('../rsrc/System/SkinTemplates/base.css');
</style>
<style type="text/css" media="all">
@import url('../rsrc/System/SkinTemplates/default.css');
</style>
<!--[if IE]><style type="text/css" media="screen">
pre {
	overflow-x:auto;
	padding-bottom:expression(this.scrollWidth > this.offsetWidth ? 16 : 0);
}
</style>
<![endif]-->

<meta name="foswiki.PUBURL" content="http://wiki.gnumed.de/pub" /> <!-- PUBURL -->
<meta name="foswiki.PUBURLPATH" content="/pub" /> <!-- PUBURLPATH -->
<meta name="foswiki.SCRIPTSUFFIX" content="" /> <!-- SCRIPTSUFFIX -->
<meta name="foswiki.SCRIPTURL" content="http://wiki.gnumed.de/bin" /> <!-- SCRIPTURL -->
<meta name="foswiki.SCRIPTURLPATH" content="/bin" /> <!-- SCRIPTURLPATH -->
<meta name="foswiki.SERVERTIME" content="10%20Mar%202013%20-%2013:43" /> <!-- SERVERTIME -->
<meta name="foswiki.SKIN" content="twikinet%2c%20pattern" /> <!-- SKIN -->
<meta name="foswiki.SYSTEMWEB" content="System" /> <!-- SYSTEMWEB -->
<meta name="foswiki.TOPIC" content="GmManualDocumentManagementConcepts" /> <!-- TOPIC -->
<meta name="foswiki.USERNAME" content="KarstenHilbert" /> <!-- USERNAME -->
<meta name="foswiki.USERSWEB" content="Main" /> <!-- USERSWEB -->
<meta name="foswiki.WEB" content="Gnumed" /> <!-- WEB -->
<meta name="foswiki.WIKINAME" content="KarstenHilbert" /> <!-- WIKINAME -->
<meta name="foswiki.WIKIUSERNAME" content="Main.KarstenHilbert" /> <!-- WIKIUSERNAME -->
<meta name="foswiki.NAMEFILTER" content="%5b%5cs%5c*%3f~%5e%5c%24%40%25%60%22'%26%3b%7c%3c%3e%5c%5b%5c%5d%23%5cx00-%5cx1f%5d" /> <!-- NAMEFILTER --><!--JQUERYPLUGIN::FOSWIKI::META-->
<script type='text/javascript' src='../rsrc/System/JQueryPlugin/jquery-1.4.3.js'></script><!--JQUERYPLUGIN-->
<script type='text/javascript' src='../rsrc/System/JQueryPlugin/plugins/livequery/jquery.livequery.js'></script><!--JQUERYPLUGIN::LIVEQUERY-->
<script type='text/javascript' src='../rsrc/System/JQueryPlugin/plugins/foswiki/jquery.foswiki.js'></script><!--JQUERYPLUGIN::FOSWIKI-->
<script type='text/javascript' src='../rsrc/System/JSTreeContrib/jquery.jstree.js'></script><!--JQUERYPLUGIN::JSTREE-->
</head>
<body class=""><div class="foswikiPage">
<a name="PageTop"></a> 
<p></p>
<p></p>
<h1><a name="Understanding_the_GNUmed_document_management_system"></a>  Understanding the GNUmed document management system </h1>
<p></p>
<h2><a name="Archive_concepts"></a>  Archive concepts </h2>
<p></p>
<h3><a name="What_the_archive_is_42not_42"></a>  What the archive is <strong>not</strong> </h3>
<p></p>
The document archive is not intended to be used as a RIS (Radiology Information System) or full-blown DICOM compatible PACS. It has not been designed to efficiently handle huge amounts of image data. Use dedicated software (and hardware) for that such as <a href="http://www.rad.unipd.it/progetti/raynux/rayUK.php3" target="_top">Raynux</a>, <a href="http://www.osirix-viewer.com/" target="_top">OsiriX</a>, <a href="http://ginkgo-cadx.com/" target="_top">Ginkgo CADx</a>, <a href="http://www.dcm4che.org/" target="_top">dcm4che</a>, etc. Having said that, if an occasional patient should present to you with images obtained elsewhere, and you had not yet set up a separate system, GNUmed will certainly store such images for you.
<p></p>
<h3><a name="What_the_archive_42is_42"></a>  What the archive <strong>is</strong> </h3>
<p></p>
The GNUmed medical document archive is a repository designed with the average GP office in mind. Its technical foundations have been in practical use in one office for a few years already. The archive can be used to store digitized paper documents and existing digital documents such as fax transmissions, voice messages, or ultrasound images. <em>Optionally</em>, the archive can serve to simply <em>catalog</em> important parts of a patient's record, while leaving the content stored in its original (paper chart, online repository) location. For those who would desire to use GNUmed in this way, a configuration option can be set to allow the saving of so-called "empty" documents.
<p></p>
<h3><a name="The_Document"></a>  The <em>Document</em> </h3>
<p></p>
A document is a collection of possibly several objects (<em>parts</em>) which together form a medically consistent whole. When exported from the archive a document may consequently consist of one or several files. A document will be associated with a few properties such as a report or medical content "type"; a date of clinical origin (the point in time the <strong>content</strong> of the document pertains to); and a short comment. The properties and objects of the document will be presented together to form a coherent picture.
<p></p>
<h3><a name="The_Document_Part"></a>  The <em>Document Part</em> </h3>
<p></p>
A document part represents one of the technical artifacts (objects) which make up a document, equivalent to a file. Each part may contain one or more pages of a text report, PDF file, scan, a movie, a sound recording, an e-mail, etc and becomes linked to the new document of which it will form a part. Also, each part has a sequence number by which the order of parts within the document can be defined. The provider (reviewer) who is to take clinical responsibility for acknowledging and actioning the document is assignable.
<p></p>
<h3><a name="The_Review"></a>  The <em>Review</em> </h3>
<p></p>
Clinical documents should be reviewed and signed off as such. By signing a document, the reviewer takes responsibility to initiate proper clinical action based on the content of the document. The signature will be attached to each part of the document individually such that no parts can be added to a document later and automatically fall under the scope of a document-wide signature. There can only be one review per provider per document part. With each review it must be decided whether the content is deemed technically abnormal (out of range) and whether it is of further clinical significance. Note that both normal and abnormal results can be of clinical significance, for example to reflect that an important diagnostic or treatment question had been thoroughly investigated.
<p></p>
Note that once someone reviews a document, that review cannot be removed anymore. It can be <strong>modified</strong> at any time, however, to reflect the current thinking about the clinical relevance and abnormality of the document.
<p></p>
<h3><a name="The_Reviewer"></a>  The <em>Reviewer</em> </h3>
<p></p>
Any clinician can review any clinical document to which she has access. Each reviewer may only attach one review to each document (but the review can be changed if necessary). Interpretations (technical abnormality and clinical significance) need not coincide among reviewers. Two reviews will be presented more prominently among the existing ones: A review by the user currently logged into the GNUmed client and a review by the healthcare provider who is actually responsible for this document.
<p></p>
<h3><a name="Supported_Document_Formats"></a>  Supported Document Formats </h3>
<p></p>
The GNUmed document archive is not restricted to any data format in any way. The only current restriction is in the technical ability of PostgreSQL to store large data, the only significant limit being that a document <em>part</em> can at most be about 1 GB in size at the moment.
<p></p>
In other words, <strong>any</strong> data format <em>can</em> be stored in the document archive.
<p></p>
The ability to display, edit, or process (print, email) the documents entirely depends on the capability and configuration of your operating system in exactly the same way standard e-mail does.
<p></p>
<h2><a name="Workflow"></a>  Workflow </h2>
<p></p>
When using GNUmed's document management system from within the integrated user interface, the workflow is optimized towards completely digitalizing and indexing one medical document at a time. This includes a full cycle of acquiring parts of a document, associating them with required and optional metadata, and saving them into the medical record of a patient. Only then can the next document be started. One document can, of course, consist of several pages, files, etc. A somewhat more technical filenote is archived <a href="http://lists.gnu.org/archive/html/gnumed-devel/2006-01/msg00141.html" target="_top">here</a>.
<p></p>
The user will then use the document tree to retrieve and display existing documents. She will possibly want to attach a review to them to signal that clinical responsibility has been taken for a document.
<p></p>
The assigned-as-responsible clinician will be notified automatically about newly imported documents via his or her Inbox.
<p></p>
This is handled in the next topic, <a href="GmManualDocumentImporter.html">Importing documents</a>.
<p></p>
<a name="TopicEnd"></a>
<p></p>
<p></p>
<p></p>
<p></p>
</div>
</body></html>