This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "RIMBAA: xEhra"

From HL7Wiki
Jump to navigation Jump to search
(New page: category:RIMBAA ''This page uses terminology as defined in [http://www.ringholm.de/docs/03100_en.htm this whitepaper].'' *Note: descritopn in Dutch only - translation is pending xEhr...)
 
 
Line 1: Line 1:
 
[[category:RIMBAA]] ''This page uses terminology as defined in [http://www.ringholm.de/docs/03100_en.htm this whitepaper].''
 
[[category:RIMBAA]] ''This page uses terminology as defined in [http://www.ringholm.de/docs/03100_en.htm this whitepaper].''
  
*Note: descritopn in Dutch only - translation is pending
+
The eXtensible Electronic health record architecture (xEhra) is based on a small set of simple, RIM based, models. By means of referencing and recursion it is possible to construct more complex models. The approach is very similar to the Care Provision domain model, the main difference is that xEhra use lots of CMETS in the clinical statement choice.
  
xEhra is gebaseerd op een beperkt aantal, RIM gebaseerde, eenvoudige modellen waarmee d.m.v. recursie en referenties complexe modellen kunnen worden opgebouwd. De aanpak lijkt op wat er in Care Provision wordt gedaan, maar het verschil is dat xEhra met CMET's werkt als clinical statements. Alles is in een native XML database (eXist-db) opgeslagen, recursie en referenties zijn 'by reference' m.b.v. identifiers (II datatype) gerealiseerd.
+
Persistence of the data is achieved by means of the eXist-db open source native XML database. All recursion and referencing is 'by reference' using the II datatype, this is done to keep the size of the XML documents in check.
  
Voor de weg van database naar UI zijn de volgende blokken gebruikt:
+
The following techmatrix blocks are used:
 
*MP-MO-MS
 
*MP-MO-MS
*MP naar MO gaat d.m.v. xQuery
+
*MP to MO transition is by means of xQuery.
*MO naar MS gaat d.m.v. xslt
+
*MO to MS transition is by means of xslt.
  
De huidige implementatie gebruikt het Apache Cocoon forms framework voor de UI, deze is geheel web-based. De referentiële integriteit wordt bewaakt in de Cocoon forms, er kan alleen valide xml naar de database worden geschreven.
+
The current implementation uses the Apache Cocoon forms framework for building the user interface (UI). Referential integrity is maintained by the Cocoon forms, only valid XML can be saved to the database.
  
Messaging wordt op dit moment niet ondesteund maar zouden alsvolgt kunnen worden gerealiseerd:
+
Messaging is currently not supported but could be implemented as follows:
Binnenkomende messages worden in een xml collection geplaatst, deze collection bevat een trigger (net als triggers op tabellen in een RDBMS) i.d.v.v. een xQuery. De xQuery verwerkt de message en roept evt. andere xQueries aan om de response samen te stellen.
+
*Incoming messages are placed in a database collection, this collection contains an xQuery trigger (like triggers on tables in a RDBMS) which processes the message, either directly, or by calling other xQueries.

Latest revision as of 18:22, 21 January 2009

This page uses terminology as defined in this whitepaper.

The eXtensible Electronic health record architecture (xEhra) is based on a small set of simple, RIM based, models. By means of referencing and recursion it is possible to construct more complex models. The approach is very similar to the Care Provision domain model, the main difference is that xEhra use lots of CMETS in the clinical statement choice.

Persistence of the data is achieved by means of the eXist-db open source native XML database. All recursion and referencing is 'by reference' using the II datatype, this is done to keep the size of the XML documents in check.

The following techmatrix blocks are used:

  • MP-MO-MS
  • MP to MO transition is by means of xQuery.
  • MO to MS transition is by means of xslt.

The current implementation uses the Apache Cocoon forms framework for building the user interface (UI). Referential integrity is maintained by the Cocoon forms, only valid XML can be saved to the database.

Messaging is currently not supported but could be implemented as follows:

  • Incoming messages are placed in a database collection, this collection contains an xQuery trigger (like triggers on tables in a RDBMS) which processes the message, either directly, or by calling other xQueries.