Hi,
My 2 cents:
A standard is not a technical 'thing' - its an agreement between people to
behave in a predefined way. Developing the predefined approach is the easy part
- getting the agreement is much harder. To achieve this, the advantages of
agreeing have to outweigh the advantages of independence. This does happen -
the MS Word format is the de facto standard for word processing documents,
despite its limitations. In health care I think its more likely we will see an
evolutionary struggle, with different standards at first co-existing in
different niches, and then converging in an awkward but workable way. Everyone
adopting a single, rational overarching solution would result in a better
solution but we live in an imperfect world.
BWs
Derek.
On 06/05/11, "Athanassios I. Hatzis, PhD" <hatzis at healis.gr> wrote:
>
> <!--
> /* Font Definitions */
> @font-face
> {font-family:Calibri;
> panose-1:2 15 5 2 2 2 4 3 2 4;}
> @font-face
> {font-family:Tahoma;
> panose-1:2 11 6 4 3 5 4 4 2 4;}
> /* Style Definitions */
> p.MsoNormal, li.MsoNormal, div.MsoNormal
> {margin:0cm;
> margin-bottom:.0001pt;
> font-size:12.0pt;
> font-family:"Times New Roman","serif";
> color:black;}
> a:link, span.MsoHyperlink
> {mso-style-priority:99;
> color:blue;
> text-decoration:underline;}
> a:visited, span.MsoHyperlinkFollowed
> {mso-style-priority:99;
> color:purple;
> text-decoration:underline;}
> p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
> {mso-style-priority:34;
> margin-top:0cm;
> margin-right:0cm;
> margin-bottom:0cm;
> margin-left:36.0pt;
> margin-bottom:.0001pt;
> font-size:12.0pt;
> font-family:"Times New Roman","serif";
> color:black;}
> span.EmailStyle17
> {mso-style-type:personal-reply;
> font-family:"Calibri","sans-serif";
> color:#1F497D;}
> .MsoChpDefault
> {mso-style-type:export-only;
> font-size:10.0pt;}
> @page WordSection1
> {size:612.0pt 792.0pt;
> margin:72.0pt 90.0pt 72.0pt 90.0pt;}
> div.WordSection1
> {page:WordSection1;}
> /* List Definitions */
> @list l0
> {mso-list-id:1649673877;
> mso-list-type:hybrid;
> mso-list-template-ids:526397888 67698703 67698713 67698715 67698703
> 67698713 67698715 67698703 67698713 67698715;}
> @list l0:level1
> {mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-18.0pt;}
> @list l0:level2
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-18.0pt;}
> @list l0:level3
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> text-indent:-9.0pt;}
> @list l0:level4
> {mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-18.0pt;}
> @list l0:level5
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-18.0pt;}
> @list l0:level6
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> text-indent:-9.0pt;}
> @list l0:level7
> {mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-18.0pt;}
> @list l0:level8
> {mso-level-number-format:alpha-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:left;
> text-indent:-18.0pt;}
> @list l0:level9
> {mso-level-number-format:roman-lower;
> mso-level-tab-stop:none;
> mso-level-number-position:right;
> text-indent:-9.0pt;}
> ol
> {margin-bottom:0cm;}
> ul
> {margin-bottom:0cm;}
> -->
>
>
>
>
> Hi Thomas,
>
> I will agree with you, yes there has to be a generic health information model
> but in my opinion it has to span over all three main layers of software
> architecture
>
> 1.?????? Physical/persistence layer
>
> 2.?????? Conceptual/Application/Object layer
>
> 3.?????? User interface layer/Serialized representation (XML,etc....)
>
> ?
>
> RIMBAA technology matrix describes in the best way the different paths one
> can follow to solve parts of the generic problem.
>
> ?
>
> The big challenge in my opinion is that there has not been an OPEN
> IMPLEMENTATION of a generic framework to cover all these layers.
>
> ?
>
> I have studied a bit the underlying structure of openEHR
> archetypes/templates, where you are linking/binding user interface fields
> with clinical/admin entries of the conceptual layer in one serialized object
> (ADL). By the way I am not convinced that there has to be strong binding
> between user interface and the conceptual layer (RIM). But clearly you are
> leaving out the mapping of data captured from the forms (templates) to the
> company that is going to provide the database management system in order to
> store permanently the user data. Of course the aggregation of user data is
> also important in that case and I cannot see any open approach that is taken
> from your side to cover or support that process. Obviously I can also realize
> that there has to be a business model and profit out of that story and if
> everything is open and free then many might go out of business.
>
> ?
>
> Anyway, let me continue a bit on ONE GENERIC e-health FRAMEWORK. One reason I
> started the MEDILIG approach is because I realized that there has not been an
> extensive, generic, easy to follow, standalone, OPEN ER schema in e-health to
> cover the persistence layer am I wrong ? Developers do need to work with an
> open database schema because that schema is closely related to the
> conceptual/object model for programming purposes, business logic is shared
> between the two as developers do know.
>
> ?
>
> Question: Has anyone thought to IMPLEMENT an open conceptual framework and
> generate from there a generic ehealth database model because that is what I
> am exactly trying to implement using the programming environment of Microsoft
> Entity framework and the RIM model of HL7. In fact this way I am turning
> MEDILIG to an entity framework standardized through HL7 RIM and HL7
> vocabularies.
>
> ?
>
> One may realize the consequences of such an implementation. Developers can
> built user interfaces of any kind, produce serializations, do mappings from
> any forms created with other software tools, and make it easier to connect or
> redesign legacy ehealth applications and databases. Or at least that is the
> way I envisage it to happen....
>
> ?
>
> One idea I have is that the framework can be specialized according to each
> specialty and therefore you can make it even easier for a developer to
> approach and implement a specific solution for an individual, a clinic, a
> lab, etc....
>
> ?
>
> What I DO NOT have is capital, resources or even an employer interested in
> such a business plan, where I can understand it up to a point ???!!!
>
> ?
>
> Best luck to all
>
> ?
>
> Athanassios
>
> ?
>
> PS1: Apologies to the non-technical audience for getting a bit into technical
> details ;=)
>
> ?
>
> PS2: The approach I am suggesting is taking the developer at the center of
> the solution and attempts to standardize concepts, terms, properties, etc
> around him. ?One the other hand the user interface design should take the
> clinician/health professional at the center and try to standardize the
> software world around him. You have already achieved that at a great level I
> believe. Then the two worlds have to be linked/mapped.
>
> ?
>
> ?
>
> ?
>
> ?
>
> ?
>
> ?
>
> ?
>
> From: openehr-clinical-bounces at openehr.org
> [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Thomas Beale
> Sent: Thursday, May 05, 2011 7:21 PM
> To: Openehr-Technical; For openEHR clinical discussions
> Subject: on the possibility of 'one information model' in e-health
>
>
>
> ?
>
>
> this is an often debated question, and after coming across (for the 100th
> time) just such a debate recently online, I thought it might be interesting
> to try to get to the bottom of the question in some way. The basic idea
> posted here(http://wolandscat.net/2011/05/05/no-single-information-model/).
> It is of course not scientific work, but I would be interested in the views
> of others on this concept.
>
> - thomas beale
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110506/598944c2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmeyer.vcf
Type: text/x-vcard
Size: 187 bytes
Desc: Card for "Derek Meyer" <dmeyer at sgul.ac.uk>
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110506/598944c2/attachment.vcf>
