Zorginformatiebouwstenen - Gebruikersbijdragen [nl]

Information model: diagram

2012-12-14T13:14:34Z

Sjaak Gondelach: /* Valueset vermelding */

== Auteursnaam instellen ==

== Versie beheer ==

== Classes toevoegen ==
*'''Naamgeving concepten'''
In de CCR hebben generieke concepten als 'Description' logischerwijs in alle secties dezelfde naam. Indien deze naamgeving in de bouwstenen overgenomen wordt, ontstaan er veel items met dezelfde naam (evt. zelfs binnen de bouwsteen). Daaarom moeten generieke namen, indien deze tot verwarring kunnen leiden, verder verbijzonderd worden. 
Conventie voor verbijzondering: Generiekenaam wordt VerbijzonderingGeneriekenaam (bv. Status wordt AlertStatus)

*'''Definitie concepten'''
Als een klasse met stereotype 'Rootconcept' of 'Container' wordt toegevoegd, wordt tenminste de volgende standaardtekst opgenomen in de definitie:
<li>Voor Rootconcepten: ''“Rootconcept van de bouwsteen <naam>. Dit rootconcept bevat alle gegevenselementen van de bouwsteen <naam>."''
<li>Voor Containers: ''“Container van het concept <naam>. Deze container bevat alle gegevenselementen van het concept <naam>."
'' 
Voor de overige concepten bevat de definitie een korte maar heldere omschrijving van het concept. Overwegingen die geleid hebben tot deze tekst, horen hier niet bij. Soms is het noodzakelijk om naast de definitie iets op te nemen over de context waarin de definitie gehanteerd wordt. 

Als een klasse met stereotype 'Rootconcept' wordt toegevoegd wordt de lijndikte van de box op 3 gezet.
 

== Welke items/class vullen ==

== Codering van de concepten ==

De DCM standaard eist dat voor ieder concept een definition code gedefinieerd wordt. Zonder codering is alles betekenisloos. Daarin kan alleen een Snomed CT code staan als je zeker weet dat het de juiste is, anders moet je een eigen code opvoeren en deze goed definieren. Die “eigen” code kan ook een Snomed CT extensie zijn. Foute SNOMED codes zouden juist misverstanden kunnen introduceren doordat je toch 'misbruik' maakt van een concept uit bv SNOMED, wat eigenlijk een semantische fout introduceert. Ook zijn er vaak geen definition codes voor ons type containers. 
In de implementatie handleiding zullen we wel verwijzingen moeten opnemen. Daarvoor hebben we de definition codes ook nodig. 
 
Daarom is besloten om een eigen lijst met concept definitie codes te maken. Hiervoor is een projectOID aangevraagd en toegekend. Idem voor een eigen lijst met ValueSets en klinische bouwstenen. Deze OID komt onder de Nictiz root. 
 
*De project OID : 2.16.840.1.113883.2.4.3.11.60.40 
*De OID voor bouwstenen: 2.16.840.1.113883.2.4.3.11.60.40.3 
*De OID voor valuesets: 2.16.840.1.113883.2.4.3.11.60.40.2 (substituut hele OID = NL-CM-VS) 
*De OID voor elementen: 2.16.840.1.113883.2.4.3.11.60.40.1 (substituut hele OID = NL-CM) 
 
In de DCM nemen we per concept een DCM::DefinitionCode op in de vorm: 
DCM::DefinitionCode = NL-CM: <sectienummer>.<DCMvolgnummer>.<elementnummer> 
NL-CM staat voor : "Netherlands Content Models Elements". 

We gebruiken in de DCM::DefinitionCodes de volgende aliases, zodat we niet steeds het hele lange OID hoeven in te tikken:
*2.16.840.1.113883.2.4.3.11.60.40.1 = Content Models Elementen (alias 'NL-CM')
*2.16.840.1.113883.2.4.3.11.60.40.2 = Content Modules ValueSets (alias 'NL-CM-VS' )
*2.16.840.1.113883.2.4.3.11.60.40.3 = DCM bouwstenen (Geen alias. Wordt alleen in de metagegevens gebruikt. Daar schrijven we de OID voluit). 
 
In het geval van Content Models Elements wordt de notatie ‘root:extensie’ gebruikt. De root is NL-CM (=2.16.840.1.113883.2.4.3.11.60.40.1) en de extensie heeft de vorm x.y.z waarin:
*X = sectienummer
*Y = DCM volgnummer (1 sectie kan meerdere DCM’s omvatten)
*Z = elementvolgnummer 
Bij de elementnummering wordt begonnen bij het rootconcept. Dit krijgt elementnummer 1. Voor de overige elementen wordt geen vaste volgorde voorgeschreven. 
Voorbeeld:
De eerste elementen van de eerste Bouwsteen in sectie social history zijn NL-CM:7.1.1, NL-CM:7.1.2 etc.
De elementen van de tweede Bouwsteen zouden dan zijn NL-CM:7.2.1, NL-CM:7.2.2 etc.

Voor valuesets wordt gebruikelijk geen notatie in de vorm van een root en een extensie gebruikt, maar wordt achter de root OID doorgenummerd, met punten als scheidingsteken. Een alias is hierbij niet gebruikelijk. In ieder geval tot er een projectOID is kunnen we de alias wel gebruiken. De notatie voor de valuesets wordt dan: NL-CM-VS.x.y.z, echter Z is hier het volgnummer van de valueset binnen de DCM en niet het volgnummer van het element waar de valueset bij hoort. (let op het verschil in notatie, een ‘.’ ipv ‘:) 
Voorbeeld:
De eerste valueset/codelijst in de eerste DCM binnen de sectie social history is dan 2.16.840.1.113883.2.4.3.11.60.40.2.7.1.1

Voor DCM’s is de nummering in de vorm: 
Project OID.3.x.y waarin:
*X = sectienummer
*Y = DCM volgnummer
Als er slechts één (1) DCM in de sectie voorkomt, dan heeft Y de waarde ‘1’ (en mag dan dus niet weggelaten worden).

Samenvattend zijn de afspraken voor het coderen van de element van de bouwstenen:
*Ieder element krijgt een code uit het NL-CM systeem, zoals hierboven beschreven.
*Het rootconcept krijgt binnen de bouwsteen elementnummer 1
*Het rootconcept krijgt nooit een andere(bv SNOMED-CT) code.
*Andere elementen inclusief containers kunnen wel codes uit andere codesystemen, zoals SNOMED-CT krijgen, uitsluitend als het element overeenkomt met het concept van de code.

== Generalisatie of aggregatie ==
We gebruiken zo min mogelijk specialisaties in het model. Maar als iets echt een generalisatie/specialisatie ism mag die ook zo gemodelleerd worden. 
Indien er in geval van een aggregatie slechts één element mag voorkomen, ga dan in het model als volgt te werk:
*Voeg een Boundary toe (uit de common elements van de toolbox)
*Voeg een Constraint toe met de tekst: 'Precies één concept in deze choice box moet gekozen worden' en verbindt deze constraint via een NoteLink met de Boundary. 
[[Bestand:Aggregatie.png]]

== Relaties maken ==

== Notes ==

== Constraints ==

== Subdiagrammen ==

Als een diagram te groot of te complex wordt, kan het diagram opgeknipt worden in een hoofddiagram en subdiagrammen. 
De verbinding tussen hoofd- en subdiagrammen verloopt via een gemeenschappelijke container. Als dit op de juiste manier gedaan wordt, kan met een dubbelclick op deze container in het hoofddiagram automatisch naar het subdiagram gesprongen worden. 
De werkwijze daarvoor is als volgt. Uitgangssituatie is dat er een hoofdiagram is en dat de gemeenschappelijke container daar nog niet instaat.
*Voeg aan het Information Model een nieuw package toe.
*Indien dit niet automatisch gebeurt, voeg aan dit package een class diagram toe. 
[[Bestand:AddPackage.png|text-top]][[Bestand:NewDiagram2.png|text-top|right]] [[Bestand:NewDiagram.png|text-top]] 

*Vul het diagram met de gewenste concepten incl. de gemeenschappelijke container.
*Verplaats in de Project Browser het diagram naar de gemeenschappelijke container.
 
[[Bestand:NewDiagram3.png|left]] [[Bestand:NewDiagram4.png|center]] 
*Selecteer in het subdiagram de container en kies via de rechtermuisknop 'Advanced > Composite'.
*Sleep het diagram in de Project Browser terug naar de oorspronkelijke plaats.
*Ga naar het hoofddiagram en sleep de gemeenschappelijke container vanuit de Project Browser naar het diagram als 'Simple Link'.
 
[[Bestand:Hoofddiagram.png|left|frame|Hoofddiagram]] [[Bestand:Subdiagram.png|center|frame|Submenu]]
 

== Verwijzingen naar andere bouwstenen ==
===Algemeen===

Als in een bouwsteen verwezen wordt naar een andere bouwsteen of een concept in een andere bouwsteen wordt een generieke klasse aangemaakt met stereotype <<context>> en <<reference>>. N.B. Stereotype ‘context’ moet evt aangemaakt worden. 
De naam van de klasse wordt ''Conceptnaam''::''GerefereerdeConceptnaam''.
De eerste conceptnaam is de naam in de verwijzende bouwsteen, de tweede is de naam in de de bouwsteen waarna verwezen wordt.
Beide conceptnamen benoemen is niet verplicht. Dit wordt alleen gebruikt als het nodig en zinvol is. In de minimale vorm is de naam van de klasse ''GerefereerdeConceptnaam''. De hele tekst van de klasse heeft 40% grijs als kleur (dit wordt een eigenschap van het stereotype, actie Michael). 
De verwijzing wordt gecomplementeerd door bij het verwijzende concept de tag DCM::DCMIdentifier te vullen met de GUID van het concept waarnaar verwezen wordt. [[EA tips en tricks#Hoe kopieer je de GUID van een concept | (Hoe? zo!)]] 
Bovendien wordt in het notes-veld bij de DCM::DCMIdentifier de volgende tekst opgenomen: “Dit is een verwijzing naar de bouwsteen XXXXX”, zodat ook voor de menselijke lezer duidelijk is naar welk concept verwezen wordt. 
[[Bestand:Bouwsteenverwijzing.png]]

===Zorgverleners===

Zorgverleners komen in vrijwel alle secties voor. 
Indien in deze secties het vermelden van deze betrokkenen klinisch relevant is, wordt dit gedaan door een verwijzing naar zorgverlener. 
De modellering van zorgverlener verbeurt eenmalig in sectie 0. 

== Valuesets en codes ==
===Valueset vermelding===

Bij een concept van het type CD wordt het waardebereik vastgelegd in een 'losse' valueset die in een document artifact aan het bijbehorende concept wordt gerelateerd (en dus '''niet''' als enumeratie attributen van dat concept). 
Iedere valueset (dus ieder document artifact) krijgt een tagged value 'DCM::Valueset' waarbij het note veld gevuld wordt met de naam van de valueset en de OID van die valueset. Hiermee wordt de naam van de valueset aan de OID van die valueset gekoppeld. 
Voorbeeld:
DCM::Valueset = SocialeAnamneseTypeCodelijst OID: 2.16.840.1.113883.2.4.3.11.60.40.2.7.1.1

Bij het concept waarop één of meer valuesets van toepassing zijn, worden alle relevante valuesets in een tagged value (DCM::Valueset) vermeld, ook de valuesets die als een document artifact aan dat concept zijn gerelateerd.

In tegenstelling tot hetgeen gebruikelijk is bij DCM's, spreken we voor dit project af, dat als er meer valuesets bij een concept genoemd worden, bij implementatie niet gekozen hoeft te worden uit één van de sets, maar dat het waardebereik de verzameling van alle vermeldde valuesets is.

===Naamgeving en nummering===
Alle valueset hebben een naam en een nummer in de vorm van een OID.
Soms kunnen voor de bouwsteen betaande valuesets gebruikt worden. Als zo'n valueset in zijn geheel overgenomen wordt, dus zonder uitbreidingen of inperkingen, wordt de oorspronkelijke naam en OID gebruikt. In alle andere gevallen wordt zelf een naam en een OID toegekend. 
Hierbij is de afspraak, dat
*de naam wordt <Conceptnaam>Codelijst , waarbij <Conceptnaam> vervangen wordt door de naam van het concept waar de valueset aan gekoppeld is.
* de OID wordt toegekend zoals in [[#Codering van de concepten|'Codering van de concepten']] is beschreven.
 

===Opstellen valueset===
Indien het waardebereik niet wordt vastgelegd in een losse valueset maar als enumeratie, is er voor gekozen dit niet te doen als enumeratie attributen bij het concept maar de waardenlijst aan aan het concept te koppelen middels een ‘document artifact’ (uit de Common elements). Dit doen we in alle gevallen voor enumeratie, dus niet alleen voor lange waardelijsten, maar ook voor korte. 

Werkwijze:
* In de toolkit op ProjectPlace vind je een Word-template waarin je de waardelijst kunt intikken (template voor valuesets.docx).
* Hierbij geldt de afspraak dat in de kolom ConceptName de de beschrijving staat zoals die in het codesysteem gegeven wordt. Dit zal dus vaak een Engelse term zijn. In de kolom Description komt de Nederlandse vertaling van het begrip met eventueel een additionele toelichting.
* Sleep een "Document" component uit de "Common" sectie van de toolbox naar het diagram.
* DoubleClick op het 'artifact'
* De document editor gaat dan open. Plak via copy/paste de waardelijst (tabel) uit het Word-document in de document editor. 
[[Bestand:CreateArtifact.PNG]] 
* Sluit de document editor.
* Het document wordt vervolgens met het concept verbonden met een ‘Dependency Link’. Vervolgens wordt de pijlkop van de link verwijderd door met de rechtermuisknop te kiezen: Advanced->Change Directions->Unspecified 
Note: Doe dit eenmalig en edit daarna eventuele wijzigingen direct in de document editor van EA. Dit om te voorkomen dat je de waardelijst op twee plaatsen (in het Word-bestand en in EA) actueel moet houden.

Omdat niet alle Value sets even goed beschikbaar zijn, zou ik willen voorstellen in dit document artifact een kopie van de set op te nemen met de naam van de beherende instantie erbij. Anders blijven die in spreadsheets staan.

[[Bestand:Valueset.png]]

===Waarden buiten Valueset===

Elk concept van het type CD heeft naast de value set een ‘overige’ mogelijkheid om te voorkomen dat bij gebrek aan een juiste waarde een foute waarde geselecteerd wordt (zeker bij verplichte items). Afspraak is dat deze overige waarden niet gecodeerde vrije tekst is. (in HL7 zal dit nullflavour OTH zijn met de tekst in originalText)

Bovenstaande geldt ook voor datatype CO

Overige DCM sectie: wat komt er in

2012-12-07T10:39:13Z

Sjaak Gondelach: /* Traceability to other Standards */

== Metadata ==
{|style="color: black; background-color: #ffffcc;" width="70%" class="wikitable"
|+
! style="width: 40%"; align="left" |Tag
! style="width: 60%"; align="left" |Waarde
|-
|DCM::CoderList||''Lijst met codeurs namen gescheiden door komma's, format: naam (e-mailadres), naam (e-mailadres), ...''
|-
|DCM::ContactInformation.Address||
|-
|DCM::ContactInformation.Name||
|-
|DCM::ContactInformation.Telecom||
|-
|DCM::ContentAuthorList||''Lijst met de namen (geen e-mail adressen ) van alle leden van de werkgroep van de betreffende CCR sectie ''
|-
|DCM::CreationDate||''Aanmaakdatum''
|-
|DCM::DeprecatedDate||
|-
|DCM::DescriptionLanguage||'''nl'''
|-
|DCM::EndorsingAuthority.Address||
|-
|DCM::EndorsingAuthority.Name|| '''NFU'''
|-
|DCM::EndorsingAuthority.Telecom||
|-
|DCM::Id|| ''2.16.840.1.113883.2.4.3.11.60.40'''''.3.'''''<sectienummer>'''''.'''''<DCMvolgnummer>''
|-
|DCM::KeywordList||''Lijst met keywords gescheiden door komma's''
|-
|DCM::LifecycleStatus||
|-
|DCM::ModelerList||''Lijst met modelleurs
|-
|DCM::Name||''DCM naam, format:'' '''"nl.nfu.Overdracht'''''(sectie of DCM naam)'''''"'''
|-
|DCM::PublicationDate|| *
|-
|DCM::PublicationStatus|| *
|-
|DCM::ReviewerList||'''Projectgroep generieke overdrachtsgegevens'''
|-
|DCM::RevisionDate||
|-
|DCM::Superseeds||
|-
|DCM::Version||''Versie, zorg ervoor dat deze overeenkomt met de versie in "Revision history" ''
|}

De vetgedrukte waarden zijn vaste waarden

== Mindmap ==
'''Optioneel''' 
Informeel en schetsmatig overzicht van de variabelen in de DCM, inclusief hun onderlinge relaties. 
Dit kan een plaatje zijn of een mindmap in EA. 
Voeg eventueel een nieuwe package toe aan de DCM en noem deze 'Mindmap' (zie ook [[Importeren/exporteren#Plaatjes in diagrammen|Hoe importeer ik een plaatje]] resp. [[EA tips en tricks#Mindmap in EA |Mindmap in EA]]) 

== Revision History ==
'''VERPLICHT''' 
Een beknopte opsomming van de wijzigingen bij de nieuwe versie van een DCM.
NB: bij een finale versie, voor publicatie alle draft naar draft revision history verwijderen. Vaak niet zo interessant om daar naar te kijken als tussenliggende versies toch niet in repository zitten.

Voorbeeld:
0.1 2012-06-01 Initiële versie
0.2 2012-06-21 commentaar Piet verwerkt

== Concept ==
'''VERPLICHT''' 
Beschrijft de inhoud van het concept

Voorbeeld:
Deze DCM zal ingaan op het vaststellen van het risico op decubitus met behulp van de Braden schaal.
De Braden schaal is een van de meetinstrumenten waarmee het risico op decubitus kan worden vastgesteld

== Purpose ==
'''VERPLICHT''' 
Zo kort en duidelijk mogelijke beschrijving van het doel van het concept dat wordt beschreven in de DCM

Voorbeeld:
Een goed overzicht van door zorgverleners beschreven behandelaanwijzingen en wensen van de patiënt t.a.v. gewenste behandelingen is belangrijk
voor de overdracht naar andere behandelaars. Vooral in de acute situatie is een beknopt en overzichtelijke lijst van belang.
De ontvanger kan het overzicht gebruiken om de bestaande behandelaanwijzingen met de patiënt, zijn familie of gevolmachtigde te bespreken
en om het in het eigen beleid op te nemen.

== Evidence Base ==
'''Optioneel''' 
Er dient een zorgvuldige afweging te worden gemaakt over wat wel/niet wordt opgenomen in de DCM. Een wetenschappelijke onderbouwing gaat echter te ver en hierin wijken we af van de standaard.
In dit onderdeel moet waar relevant worden aangegeven waarom bepaalde keuzes zijn gemaakt (b.v. AGB codes omdat dit in alle zorginstellingen beschikbaar is en we het niet moeilijker willen maken dan het al is)

Voorbeeld:
De ontwikkeling van deze klinische bouwsteen is in eerste instantie gebaseerd op de specificatie van de CCR documentatie (Continuity of Care Record,
ASTM). De codering binnen het domein Medicatie zijn voor zo ver mogelijk gebaseerd op de G-standaard (beheeerd door de KNMP). De reden hiervoor
is, dat in Nederland vrijwel alle softwarepaketten voor electronisch voorschrijven, apotheekmanagement, medicatiebewaking op deze standaard
gebaseerd zijn. De G-standaard wordt nauwkeurig bijgehouden en ontwikkeld in overleg met belangrhebbenden, inclusief de softwareleveranciers.

Bij het bepalen van restricties en de aanwijzing van toe te passen gegevensdomeinen (valuesets) is rekening gehouden met
- landelijke richtlijn medicatieoverdracht (http://www.medicatieoverdracht.nl)
- Implementatiehandleiding HL7 v3 medicatiegegevens (NICTIZ, HL7 Nederland)
- Dataset Medicatieproces (http://www.nictiz.nl/module/360/590/Dataset_Medicatieproces_2011.xlsx)

== Example of the Instrument ==
'''VERPLICHT '''
In deze sectie gaan we een voorbeeld van het concept zoals het er uit ziet in een geprinte CCD/R laten neerzetten. dit is een image file zoals hieronder. Belangrijk is wel om zoveel als mogelijk voorbeelden te kiezen die de diverse onderdelen van het informatiemodel langslopen. 
[[Bestand:advancedirectives.jpg]]

NOTE: de bronfile (xls) moeten we ook meenemen als sourcefiles in beheer en over die 'rotterdamse boompjes' moeten we nog een boompje opzetten

== Instructions ==
'''Optioneel''' 
Zijn voor de zendende partij, diegene die het gaat vullen dan wel mappen naar de secties. Oppassen dat dit niet te veel richting implementatie gaat

Voorbeeld:
Het proces zal meestal bestaan uit de volgende stappen:
- opstellen en accorderen van de informatie door de zender;
- de medicatie wordt daarbij gesplitst in en aantal groepen : acutele medicatie, gestopte medicatie, laatst afgeleverde medicatie
- uitwisselen van de gegevens tussen twee informatiesystemen
De uitwerking van dit proces is afhankelijk van een groot aantal implementatiebeslissingen.

== Interpretation ==
'''Optioneel''' 
Is voor de ontvanger, wat die met die informatie moet doen. Wederom oppassen dat het niet over implementatie gaatVoorbeeld:
Voorbeeld:
Het proces zal meestal bestaan uit de volgende stappen:
- inspectie en beoordelen/controleren van de ontvangen medicatie gegevens
- importeren van aangemerkte medicatieopdrachten
- bewerken van de geimporteerde gegevens
- accorderen of valideren van het aangepaste medicatieoverzicht voor thuisgebruik of klinisch gebruik
De uitwerking van dit proces is afhankelijk van een groot aantal implementatiebeslissingen.

== Constraints ==
'''Optioneel''' 
Beschrijving hoe je het gaat gebruiken in de praktijk

Deze DCM is ontwikkeld voor de use case van generieke medische overdracht van patiënten tussen specialisten in ziekenhuizen

== Issues ==
'''Optioneel''' 
zaken die nog open staan bij het maken en releasen van de bouwsteen of die zaken die volgens de auteurs bij andere organisaties horen en nog niet (goed) zijn belegd

Voorbeeld:
Voor de codering van de indicatie voor het gebruik is SNOMED-CT het aangewezen codesysteem.
Het gebruik hiervan is complex. De Nederlandse organisatie aan wie het beheer van codestelsels is toegewezen, Dutch Hospital Data, kan vooralsnog
alleen borg staan als ook de gebruikte codestelsels, zoals de ICD voor diagnosen of ‘CBV’ voor verrichtingen die onder haar beheer staan.

Bij de valuesets x en y ontbreken nog de SNOMED CT mappingen. Deze zullen naar verwachting in een volgende release worden meegenomen.

== References ==
'''Optioneel''' 
verwijzingen naar andere bronnen zoals artikelen, websites etc. Zorg bij referentie naar een website voor een datum.

Voorbeeld:
ref1. KNMG handreiking "Tijdig spreken over levenseinde"

ref1 Elze de Groot. Dataset medicatieproces 2011. Nictiz 2011.
verkregen op <datum> via http://www.nictiz.nl/module/360/590/Dataset_Medicatieproces_2011.xlsx

ref2 Nictiz.nl. HL7v3-implementatiehandleiding medicatieproces versie 6.1.0.0. 12 oktober 2011.
verkregen op <datum> via http://www.nictiz.nl/uploaded/FILES/html_cabinet/live/Zorgtoepassing/Medicatieproces/AORTA_Mp_IH_Medicatieproces_HL7.htm

ref3 Dossier Medicatieoverzicht. verkregen op <datum>via http://www.oria.nl.

ref4 G-standaard documentatie. verkregen op <datum> via http://www.z-index.nl/

== Traceability to other Standards ==
'''VERPLICHT''' 
Relatie met andere standaarden. 
Deze klinische bouwsteen heeft een relatie met CCR (Continuity of Care Record, ASTM CCR E2369-05) en CCD (Continuity of Care Document, HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD)).

== Disclaimer ==
'''VERPLICHT''' 
Hieronder staat de standaard disclaimer die in de template.xmi zit. 
Het project ‘Generieke Overdrachtsgegevens’ besteedt de grootst mogelijke zorg aan de betrouwbaarheid en actualiteit van de gegevens in deze
Klinische Bouwsteen. Onjuistheden en onvolledigheden kunnen echter voorkomen. Het project ‘Generieke Overdrachtsgegevens’ is niet
aansprakelijk voor schade als gevolg van onjuistheden of onvolledigheden in de aangeboden informatie, noch voor schade die het gevolg is van
problemen veroorzaakt door, of inherent aan het verspreiden van informatie via het internet, zoals storingen of onderbrekingen van of fouten of
vertraging in het verstrekken van informatie of diensten door het project ‘Generieke Overdrachtsgegevens’ of door U aan het project ‘Generieke
Overdrachtsgegevens’ via een website van X of via e-mail, of anderszins langs elektronische weg. Tevens aanvaardt het project ‘Generieke
Overdrachtsgegevens’ geen aansprakelijkheid voor eventuele schade die geleden wordt als gevolg van het gebruik van gegevens, adviezen of ideeën
verstrekt door of namens het project ‘Generieke Overdrachtsgegevens’ via deze Klinische Bouwsteen. Het project ‘Generieke Overdrachtsgegevens’
aanvaardt geen verantwoordelijkheid voor de inhoud van informatie in deze Klinische Bouwsteen waarnaar of waarvan met een hyperlink of anderszins
wordt verwezen. In geval van tegenstrijdigheden in de genoemde Klinische Bouwsteen documenten en bestanden geeft de meest recente en hoogste
versie van de vermelde volgorde in de revisies de prioriteit van de desbetreffende documenten weer. Indien informatie die in de elektronische versie
van deze Klinische Bouwsteen is opgenomen ook schriftelijk wordt verstrekt, zal in geval van tekstverschillen de schriftelijke versie bepalend zijn.
Dit geldt indien de versieaanduiding en datering van beiden gelijk is. Een definitieve versie heeft prioriteit echter boven een conceptversie.
Een gereviseerde versie heeft prioriteit boven een eerdere versie.

== Copyrights ==
'''VERPLICHT''' 

De inhoud is beschikbaar onder de Creative Commons Naamsvermelding-NietCommercieel-GelijkDelen 3.0
(zie ook http://creativecommons.org/licenses/by-nc-sa/3.0/nl/)

Overige DCM sectie: wat komt er in

2012-12-07T10:38:14Z

Sjaak Gondelach: /* Traceability to other Standards */

== Metadata ==
{|style="color: black; background-color: #ffffcc;" width="70%" class="wikitable"
|+
! style="width: 40%"; align="left" |Tag
! style="width: 60%"; align="left" |Waarde
|-
|DCM::CoderList||''Lijst met codeurs namen gescheiden door komma's, format: naam (e-mailadres), naam (e-mailadres), ...''
|-
|DCM::ContactInformation.Address||
|-
|DCM::ContactInformation.Name||
|-
|DCM::ContactInformation.Telecom||
|-
|DCM::ContentAuthorList||''Lijst met de namen (geen e-mail adressen ) van alle leden van de werkgroep van de betreffende CCR sectie ''
|-
|DCM::CreationDate||''Aanmaakdatum''
|-
|DCM::DeprecatedDate||
|-
|DCM::DescriptionLanguage||'''nl'''
|-
|DCM::EndorsingAuthority.Address||
|-
|DCM::EndorsingAuthority.Name|| '''NFU'''
|-
|DCM::EndorsingAuthority.Telecom||
|-
|DCM::Id|| ''2.16.840.1.113883.2.4.3.11.60.40'''''.3.'''''<sectienummer>'''''.'''''<DCMvolgnummer>''
|-
|DCM::KeywordList||''Lijst met keywords gescheiden door komma's''
|-
|DCM::LifecycleStatus||
|-
|DCM::ModelerList||''Lijst met modelleurs
|-
|DCM::Name||''DCM naam, format:'' '''"nl.nfu.Overdracht'''''(sectie of DCM naam)'''''"'''
|-
|DCM::PublicationDate|| *
|-
|DCM::PublicationStatus|| *
|-
|DCM::ReviewerList||'''Projectgroep generieke overdrachtsgegevens'''
|-
|DCM::RevisionDate||
|-
|DCM::Superseeds||
|-
|DCM::Version||''Versie, zorg ervoor dat deze overeenkomt met de versie in "Revision history" ''
|}

De vetgedrukte waarden zijn vaste waarden

== Mindmap ==
'''Optioneel''' 
Informeel en schetsmatig overzicht van de variabelen in de DCM, inclusief hun onderlinge relaties. 
Dit kan een plaatje zijn of een mindmap in EA. 
Voeg eventueel een nieuwe package toe aan de DCM en noem deze 'Mindmap' (zie ook [[Importeren/exporteren#Plaatjes in diagrammen|Hoe importeer ik een plaatje]] resp. [[EA tips en tricks#Mindmap in EA |Mindmap in EA]]) 

== Revision History ==
'''VERPLICHT''' 
Een beknopte opsomming van de wijzigingen bij de nieuwe versie van een DCM.
NB: bij een finale versie, voor publicatie alle draft naar draft revision history verwijderen. Vaak niet zo interessant om daar naar te kijken als tussenliggende versies toch niet in repository zitten.

Voorbeeld:
0.1 2012-06-01 Initiële versie
0.2 2012-06-21 commentaar Piet verwerkt

== Concept ==
'''VERPLICHT''' 
Beschrijft de inhoud van het concept

Voorbeeld:
Deze DCM zal ingaan op het vaststellen van het risico op decubitus met behulp van de Braden schaal.
De Braden schaal is een van de meetinstrumenten waarmee het risico op decubitus kan worden vastgesteld

== Purpose ==
'''VERPLICHT''' 
Zo kort en duidelijk mogelijke beschrijving van het doel van het concept dat wordt beschreven in de DCM

Voorbeeld:
Een goed overzicht van door zorgverleners beschreven behandelaanwijzingen en wensen van de patiënt t.a.v. gewenste behandelingen is belangrijk
voor de overdracht naar andere behandelaars. Vooral in de acute situatie is een beknopt en overzichtelijke lijst van belang.
De ontvanger kan het overzicht gebruiken om de bestaande behandelaanwijzingen met de patiënt, zijn familie of gevolmachtigde te bespreken
en om het in het eigen beleid op te nemen.

== Evidence Base ==
'''Optioneel''' 
Er dient een zorgvuldige afweging te worden gemaakt over wat wel/niet wordt opgenomen in de DCM. Een wetenschappelijke onderbouwing gaat echter te ver en hierin wijken we af van de standaard.
In dit onderdeel moet waar relevant worden aangegeven waarom bepaalde keuzes zijn gemaakt (b.v. AGB codes omdat dit in alle zorginstellingen beschikbaar is en we het niet moeilijker willen maken dan het al is)

Voorbeeld:
De ontwikkeling van deze klinische bouwsteen is in eerste instantie gebaseerd op de specificatie van de CCR documentatie (Continuity of Care Record,
ASTM). De codering binnen het domein Medicatie zijn voor zo ver mogelijk gebaseerd op de G-standaard (beheeerd door de KNMP). De reden hiervoor
is, dat in Nederland vrijwel alle softwarepaketten voor electronisch voorschrijven, apotheekmanagement, medicatiebewaking op deze standaard
gebaseerd zijn. De G-standaard wordt nauwkeurig bijgehouden en ontwikkeld in overleg met belangrhebbenden, inclusief de softwareleveranciers.

Bij het bepalen van restricties en de aanwijzing van toe te passen gegevensdomeinen (valuesets) is rekening gehouden met
- landelijke richtlijn medicatieoverdracht (http://www.medicatieoverdracht.nl)
- Implementatiehandleiding HL7 v3 medicatiegegevens (NICTIZ, HL7 Nederland)
- Dataset Medicatieproces (http://www.nictiz.nl/module/360/590/Dataset_Medicatieproces_2011.xlsx)

== Example of the Instrument ==
'''VERPLICHT '''
In deze sectie gaan we een voorbeeld van het concept zoals het er uit ziet in een geprinte CCD/R laten neerzetten. dit is een image file zoals hieronder. Belangrijk is wel om zoveel als mogelijk voorbeelden te kiezen die de diverse onderdelen van het informatiemodel langslopen. 
[[Bestand:advancedirectives.jpg]]

NOTE: de bronfile (xls) moeten we ook meenemen als sourcefiles in beheer en over die 'rotterdamse boompjes' moeten we nog een boompje opzetten

== Instructions ==
'''Optioneel''' 
Zijn voor de zendende partij, diegene die het gaat vullen dan wel mappen naar de secties. Oppassen dat dit niet te veel richting implementatie gaat

Voorbeeld:
Het proces zal meestal bestaan uit de volgende stappen:
- opstellen en accorderen van de informatie door de zender;
- de medicatie wordt daarbij gesplitst in en aantal groepen : acutele medicatie, gestopte medicatie, laatst afgeleverde medicatie
- uitwisselen van de gegevens tussen twee informatiesystemen
De uitwerking van dit proces is afhankelijk van een groot aantal implementatiebeslissingen.

== Interpretation ==
'''Optioneel''' 
Is voor de ontvanger, wat die met die informatie moet doen. Wederom oppassen dat het niet over implementatie gaatVoorbeeld:
Voorbeeld:
Het proces zal meestal bestaan uit de volgende stappen:
- inspectie en beoordelen/controleren van de ontvangen medicatie gegevens
- importeren van aangemerkte medicatieopdrachten
- bewerken van de geimporteerde gegevens
- accorderen of valideren van het aangepaste medicatieoverzicht voor thuisgebruik of klinisch gebruik
De uitwerking van dit proces is afhankelijk van een groot aantal implementatiebeslissingen.

== Constraints ==
'''Optioneel''' 
Beschrijving hoe je het gaat gebruiken in de praktijk

Deze DCM is ontwikkeld voor de use case van generieke medische overdracht van patiënten tussen specialisten in ziekenhuizen

== Issues ==
'''Optioneel''' 
zaken die nog open staan bij het maken en releasen van de bouwsteen of die zaken die volgens de auteurs bij andere organisaties horen en nog niet (goed) zijn belegd

Voorbeeld:
Voor de codering van de indicatie voor het gebruik is SNOMED-CT het aangewezen codesysteem.
Het gebruik hiervan is complex. De Nederlandse organisatie aan wie het beheer van codestelsels is toegewezen, Dutch Hospital Data, kan vooralsnog
alleen borg staan als ook de gebruikte codestelsels, zoals de ICD voor diagnosen of ‘CBV’ voor verrichtingen die onder haar beheer staan.

Bij de valuesets x en y ontbreken nog de SNOMED CT mappingen. Deze zullen naar verwachting in een volgende release worden meegenomen.

== References ==
'''Optioneel''' 
verwijzingen naar andere bronnen zoals artikelen, websites etc. Zorg bij referentie naar een website voor een datum.

Voorbeeld:
ref1. KNMG handreiking "Tijdig spreken over levenseinde"

ref1 Elze de Groot. Dataset medicatieproces 2011. Nictiz 2011.
verkregen op <datum> via http://www.nictiz.nl/module/360/590/Dataset_Medicatieproces_2011.xlsx

ref2 Nictiz.nl. HL7v3-implementatiehandleiding medicatieproces versie 6.1.0.0. 12 oktober 2011.
verkregen op <datum> via http://www.nictiz.nl/uploaded/FILES/html_cabinet/live/Zorgtoepassing/Medicatieproces/AORTA_Mp_IH_Medicatieproces_HL7.htm

ref3 Dossier Medicatieoverzicht. verkregen op <datum>via http://www.oria.nl.

ref4 G-standaard documentatie. verkregen op <datum> via http://www.z-index.nl/

== Traceability to other Standards ==
'''VERPLICHT''' 
Relatie met andere standaarden.
Deze klinische bouwsteen heeft een relatie met CCR (Continuity of Care Record, ASTM CCR E2369-05) en CCD (Continuity of Care Document, HL7 Implementation Guide: CDA Release 2 – Continuity of Care Document (CCD)).

== Disclaimer ==
'''VERPLICHT''' 
Hieronder staat de standaard disclaimer die in de template.xmi zit. 
Het project ‘Generieke Overdrachtsgegevens’ besteedt de grootst mogelijke zorg aan de betrouwbaarheid en actualiteit van de gegevens in deze
Klinische Bouwsteen. Onjuistheden en onvolledigheden kunnen echter voorkomen. Het project ‘Generieke Overdrachtsgegevens’ is niet
aansprakelijk voor schade als gevolg van onjuistheden of onvolledigheden in de aangeboden informatie, noch voor schade die het gevolg is van
problemen veroorzaakt door, of inherent aan het verspreiden van informatie via het internet, zoals storingen of onderbrekingen van of fouten of
vertraging in het verstrekken van informatie of diensten door het project ‘Generieke Overdrachtsgegevens’ of door U aan het project ‘Generieke
Overdrachtsgegevens’ via een website van X of via e-mail, of anderszins langs elektronische weg. Tevens aanvaardt het project ‘Generieke
Overdrachtsgegevens’ geen aansprakelijkheid voor eventuele schade die geleden wordt als gevolg van het gebruik van gegevens, adviezen of ideeën
verstrekt door of namens het project ‘Generieke Overdrachtsgegevens’ via deze Klinische Bouwsteen. Het project ‘Generieke Overdrachtsgegevens’
aanvaardt geen verantwoordelijkheid voor de inhoud van informatie in deze Klinische Bouwsteen waarnaar of waarvan met een hyperlink of anderszins
wordt verwezen. In geval van tegenstrijdigheden in de genoemde Klinische Bouwsteen documenten en bestanden geeft de meest recente en hoogste
versie van de vermelde volgorde in de revisies de prioriteit van de desbetreffende documenten weer. Indien informatie die in de elektronische versie
van deze Klinische Bouwsteen is opgenomen ook schriftelijk wordt verstrekt, zal in geval van tekstverschillen de schriftelijke versie bepalend zijn.
Dit geldt indien de versieaanduiding en datering van beiden gelijk is. Een definitieve versie heeft prioriteit echter boven een conceptversie.
Een gereviseerde versie heeft prioriteit boven een eerdere versie.

== Copyrights ==
'''VERPLICHT''' 

De inhoud is beschikbaar onder de Creative Commons Naamsvermelding-NietCommercieel-GelijkDelen 3.0
(zie ook http://creativecommons.org/licenses/by-nc-sa/3.0/nl/)

Information model: diagram

2012-11-16T09:36:31Z

Sjaak Gondelach: /* Valueset vermelding */

== Auteursnaam instellen ==

== Versie beheer ==

== Classes toevoegen ==

== Welke items/class vullen ==

== Relaties maken ==

== Notes ==

== Constraints ==

== Subdiagrammen ==

Als een diagram te groot of te complex wordt, kan het diagram opgeknipt worden in een hoofddiagram en subdiagrammen. 
De verbinding tussen hoofd- en subdiagrammen verloopt via een gemeenschappelijke container. Als dit op de juiste manier gedaan wordt, kan met een dubbelclick op deze container in het hoofddiagram automatisch naar het subdiagram gesprongen worden. 
De werkwijze daarvoor is als volgt. Uitgangssituatie is dat er een hoofdiagram is en dat de gemeenschappelijke container daar nog niet instaat.
*Voeg aan het Information Model een nieuw package toe.
*Indien dit niet automatisch gebeurt, voeg aan dit package een class diagram toe. 
[[Bestand:AddPackage.png|text-top]][[Bestand:NewDiagram2.png|text-top|right]] [[Bestand:NewDiagram.png|text-top]] 

*Vul het diagram met de gewenste concepten incl. de gemeenschappelijke container.
*Verplaats in de Project Browser het diagram naar de gemeenschappelijke container.
 
[[Bestand:NewDiagram3.png|left]] [[Bestand:NewDiagram4.png|center]] 
*Selecteer in het subdiagram de container en kies via de rechtermuisknop 'Advanced > Composite'.
*Sleep het diagram in de Project Browser terug naar de oorspronkelijke plaats.
*Ga naar het hoofddiagram en sleep de gemeenschappelijke container vanuit de Project Browser naar het diagram als 'Simple Link'.
 
[[Bestand:Hoofddiagram.png|left|frame|Hoofddiagram]] [[Bestand:Subdiagram.png|center|frame|Submenu]]
 

== Verwijzingen naar andere bouwstenen ==
===Algemeen===

Als in een bouwsteen verwezen wordt naar een andere bouwsteen of een concept in een andere bouwsteen wordt een generieke klasse aangemaakt met stereotype <context, reference>. N.B. Stereotype ‘context’ moet evt aangemaakt worden. 
De naam van de klasse wordt ''Conceptnaam''::''Bouwsteennaam''.''Conceptnaam''.
De eerste conceptnaam is de naam in de verwijzende bouwsteen, de tweede is de naam in de de bouwsteen waarna verwezen wordt.
De beide conceptnamen zijn niet verplicht en worden alleen gebruikt als het nodig en zinvol is. In de minimale vorm is de naam van de klasse ''Bouwsteennaam''. De hele tekst van de klasse heeft 40% grijs als kleur 

[[Bestand:Bouwsteenverwijzing.png]]

===Zorgverleners===

Zorgverleners komen in vrijwel alle secties voor. 
Indien in deze secties het vermelden van deze betrokkenen klinisch relevant is, wordt dit gedaan door een verwijzing naar zorgverlener. 
De modellering van zorgverlener verbeurt eenmalig in sectie 0. 

== Valuesets en codes ==
===Valueset vermelding===

Bij een concept van het type CD wordt het waardebereik vastgelegd in de enumeratie attributen of in een losse value set. 
Bij een losse valueset wordt de naam van deze set vermeld in een tagged value van het concept:

DCM::Valueset Naam van de valueset

Voor het documenteren van de koppeling van de naam van de valueset aan de OID van de valueset zijn twee plaatsen genoemd:
* sectie References van de DCM
* note van de beteffende tag value
Voor het project Generieke overdrachtsgegevens is voor de tweede mogelijkheid gekozen. 
 
Indien het waardebereik niet wordt vastgelegd in een losse valueset maar als enumeratie, is er voor gekozen dit niet te doen als enumeratie attributen bij het concept maar de waardenlijst aan aan het concept te koppelen middels een ‘document artifact’ (uit de Common elements). Dit doen we in alle gevallen voor enumeratie, dus niet alleen voor lange waardelijsten, maar ook voor korte. 

Werkwijze:
* In de toolkit op ProjectPlace vind je een Word-template waarin je de waardelijst kunt intikken (template voor valuesets.docx).
* Sleep een "Document" component uit de "Common" sectie van de toolbox naar het diagram.
* DoubleClick op het 'artifact'
* De document editor gaat dan open. Plak via copy/paste de waardelijst (tabel) uit het Word-document in de document editor. 
[[Bestand:CreateArtifact.PNG]] 
* Sluit de document editor.
* Het document en het concept worden verbonden met een ‘Note Link’ (daavoor moet het concept stereotype wel data+enumeratie zijn) 
Note: Doe dit eenmalig en edit daarna eventuele wijzigingen direct in de document editor van EA. Dit om te voorkomen dat je de waardelijst op twee plaatsen (in het Word-bestand en in EA) actueel moet houden.

Omdat niet alle Value sets even goed beschikbaar zijn, zou ik willen voorstellen in dit document artifact een kopie van de set op te nemen met de naam van de beherende instantie erbij. Anders blijven die in spreadsheets staan.

[[Bestand:Valueset.png]]

===Waarden buiten Valueset===

Elk concept van het type CD heeft naast de value set een ‘overige’ mogelijkheid om te voorkomen dat bij gebrek aan een juiste waarde een foute waarde geselecteerd wordt (zeker bij verplichte items). Afspraak is dat deze overige waarden niet gecodeerde vrije tekst is. (in HL7 zal dit nullflavour OTH zijn met de tekst in originalText)

Bovenstaande geldt ook voor datatype CO

Information model: diagram

2012-11-16T09:33:41Z

Sjaak Gondelach: /* Valueset vermelding */

== Auteursnaam instellen ==

== Versie beheer ==

== Classes toevoegen ==

== Welke items/class vullen ==

== Relaties maken ==

== Notes ==

== Constraints ==

== Subdiagrammen ==

Als een diagram te groot of te complex wordt, kan het diagram opgeknipt worden in een hoofddiagram en subdiagrammen. 
De verbinding tussen hoofd- en subdiagrammen verloopt via een gemeenschappelijke container. Als dit op de juiste manier gedaan wordt, kan met een dubbelclick op deze container in het hoofddiagram automatisch naar het subdiagram gesprongen worden. 
De werkwijze daarvoor is als volgt. Uitgangssituatie is dat er een hoofdiagram is en dat de gemeenschappelijke container daar nog niet instaat.
*Voeg aan het Information Model een nieuw package toe.
*Indien dit niet automatisch gebeurt, voeg aan dit package een class diagram toe. 
[[Bestand:AddPackage.png|text-top]][[Bestand:NewDiagram2.png|text-top|right]] [[Bestand:NewDiagram.png|text-top]] 

*Vul het diagram met de gewenste concepten incl. de gemeenschappelijke container.
*Verplaats in de Project Browser het diagram naar de gemeenschappelijke container.
 
[[Bestand:NewDiagram3.png|left]] [[Bestand:NewDiagram4.png|center]] 
*Selecteer in het subdiagram de container en kies via de rechtermuisknop 'Advanced > Composite'.
*Sleep het diagram in de Project Browser terug naar de oorspronkelijke plaats.
*Ga naar het hoofddiagram en sleep de gemeenschappelijke container vanuit de Project Browser naar het diagram als 'Simple Link'.
 
[[Bestand:Hoofddiagram.png|left|frame|Hoofddiagram]] [[Bestand:Subdiagram.png|center|frame|Submenu]]
 

== Verwijzingen naar andere bouwstenen ==
===Algemeen===

Als in een bouwsteen verwezen wordt naar een andere bouwsteen of een concept in een andere bouwsteen wordt een generieke klasse aangemaakt met stereotype <context, reference>. N.B. Stereotype ‘context’ moet evt aangemaakt worden. 
De naam van de klasse wordt ''Conceptnaam''::''Bouwsteennaam''.''Conceptnaam''.
De eerste conceptnaam is de naam in de verwijzende bouwsteen, de tweede is de naam in de de bouwsteen waarna verwezen wordt.
De beide conceptnamen zijn niet verplicht en worden alleen gebruikt als het nodig en zinvol is. In de minimale vorm is de naam van de klasse ''Bouwsteennaam''. De hele tekst van de klasse heeft 40% grijs als kleur 

[[Bestand:Bouwsteenverwijzing.png]]

===Zorgverleners===

Zorgverleners komen in vrijwel alle secties voor. 
Indien in deze secties het vermelden van deze betrokkenen klinisch relevant is, wordt dit gedaan door een verwijzing naar zorgverlener. 
De modellering van zorgverlener verbeurt eenmalig in sectie 0. 

== Valuesets en codes ==
===Valueset vermelding===

Bij een concept van het type CD wordt het waardebereik vastgelegd in de enumeratie attributen of in een losse value set. 
Bij een losse valueset wordt de naam van deze set vermeld in een tagged value van het concept:

DCM::Valueset Naam van de valueset

Voor het documenteren van de koppeling van de naam van de valueset aan de OID van de valueset zijn twee plaatsen genoemd:
* sectie References van de DCM
* note van de beteffende tag value
Voor het project Generieke overdrachtsgegevens is voor de tweede mogelijkheid gekozen. 
 
Indien het waardebereik niet wordt vastgelegd in een losse valueset maar als enumeratie, is er voor gekozen dit niet te doen als enumeratie attributen bij het concept maar de waardenlijst aan aan het concept te koppelen middels een ‘document artifact’ (uit de Common elements). Dit doen we in alle gevallen voor enumeratie, dus niet alleen voor lange waardelijsten, maar ook voor korte. 

Werkwijze:
* In de toolkit op ProjectPlace vind je een Word-template waarin je de waardelijst kunt intikken (template voor valuesets.docx).
* Sleep een "Document" component uit de "Common" sectie van de toolbox naar het diagram.
* DoubleClick op het 'artifact'
* De document editor gaat dan open. Plak via copy/paste de waardelijst (tabel) uit het Word-document in de document editor. 
[[Bestand:CreateArtifact.PNG]] 
* Sluit de document editor.
* Het document en het concept worden verbonden met een ‘Note Link’ (daavoor moet het concept stereotype wel data+enumeratie zijn) 

Omdat niet alle Value sets even goed beschikbaar zijn, zou ik willen voorstellen in dit document artifact een kopie van de set op te nemen met de naam van de beherende instantie erbij. Anders blijven die in spreadsheets staan.

[[Bestand:Valueset.png]]

===Waarden buiten Valueset===

Elk concept van het type CD heeft naast de value set een ‘overige’ mogelijkheid om te voorkomen dat bij gebrek aan een juiste waarde een foute waarde geselecteerd wordt (zeker bij verplichte items). Afspraak is dat deze overige waarden niet gecodeerde vrije tekst is. (in HL7 zal dit nullflavour OTH zijn met de tekst in originalText)

Bovenstaande geldt ook voor datatype CO

Wie gebruikt wat?

2012-09-26T19:20:40Z

Sjaak Gondelach:

'''Hierin houden we bij wie welke versie van EA gebruikt en wat het OS is''' 

{| class="wikitable"
! Naam
! versie EA
! OS
! overige info
! favoriete handicap
|-
| Linda Mook
| 9.3
| Mac OS X 10.7.4
| Crossover, MS Office 2011
| ENTP
|-
| Michael van der Zel
| 8.0 (Corporate) op Windows XP SP 3
| 9.3 (Ultimate) op Windows Vista in VMware
| Libre Office (export to PDF) & MS Office 2003 (met PDFCreator)
|-
| Jan Talmon
| 7.5 (ik ga upgraden)
| MAC OS 10.6.8
| VMWare Fusion 3.1.3, MS Office 2011
|
|-
| Sjaak Gondelach
| 9.3
| Windows XP
| MS Office 2010
| Copy vanuit OneNote gaat fout
|-
| zet hier je naam en copy
| deze sectie en de wiki tabel
| wordt vanzelf groter
| :-) amazing! :-)|}

Wie gebruikt wat?

2012-09-26T19:20:02Z

Sjaak Gondelach:

'''Hierin houden we bij wie welke versie van EA gebruikt en wat het OS is''' 

{| class="wikitable"
! Naam
! versie AE
! OS
! overige info
! favoriete handicap
|-
| Linda Mook
| 9.3
| Mac OS X 10.7.4
| Crossover, MS Office 2011
| ENTP
|-
| Michael van der Zel
| 8.0 (Corporate) op Windows XP SP 3
| 9.3 (Ultimate) op Windows Vista in VMware
| Libre Office (export to PDF) & MS Office 2003 (met PDFCreator)
|-
| Jan Talmon
| 7.5 (ik ga upgraden)
| MAC OS 10.6.8
| VMWare Fusion 3.1.3, MS Office 2011
|
|-
| Sjaak Gondelach
| 9.3
| Windows XP
| MS Office 2010
| Copy vanuit OneNote gaat fout
|-
| zet hier je naam en copy
| deze sectie en de wiki tabel
| wordt vanzelf groter
| :-) amazing! :-)|}

Importeren/exporteren

2012-07-06T07:08:21Z

Sjaak Gondelach: /* Exporteren */

==XMI bestanden==
De klinische bouwstenen kunnen op twee manieren geimporteerd en geexporteerd worden:
:# door het hele project (het .eap bestand) te kopieren
:# door de afzonderlijke bouwstenen als .xmi bestanden te distribueren.
De tweede methode is hieronder beschreven.
===Importeren===
Komt nog

===Exporteren===
Om een bouwsteen te exporteren, moet eerst de bouwsteen geselecteerd worden in de projectbrowser. 
Let op dat de bouwsteen op bouwsteenniveau (<<DCM>> nl.nfu.''DCMnaam'') geselecteerd wordt, anders wordt maar een deel geexporteerd. 
Vervolgens recht muisclick en selecteer "Import/export" > "Export package to XMI file .." 
Vul in het volgende dialoogvenster de bestandsnaam in en kies vervolgens "Publish". Vink in het dan volgende dialoogvenster de hieronder aangegeven opties aan. 
Kies "Export" om de export uit te voeren. 
 
[[Bestand:XMI_export.png]]

==RTF templates==
===Importeren===
===Exporteren===