问题
I am researching about electronic health records (EHR). OpenEHR seems to be quite extended and appreciated in this field, as it is widely adopted. However, I fail to find how it is used. I mean, I can see all the definitions for archetypes, and how those definitions are written in ADL or XML. But, once I have an archetype which is just that, a definition of a certain data model, how do I use that? Is there another type of representation, maybe also in ADL or XML? Are there any examples of actual health records for a patient? I have spent hours looking for a John Doe health record example, with info like gender, age, blood pressure and so on, but all the examples I can find are about definitions of those terms.
If anyone can put me on the right track, I would appreciate it. Thanks in advance!
回答1:
The openEHR spec describes how to write a system based on this dual layer approach...a number of companies around the world now use the architecture as the foundation for their systems. Your frustration is not new, as it is a demanding step to take. But the result is that health records can be shared by the systems, with post hoc discovery of formal meaning. The models can be written in any language, adding languages as you go....there is no language primacy.
I suggest that you subscribe to openehr.org technical mailing list and ask the same question.
Cheers Sam Heard OpenEHR Foundation
回答2:
after having the set of archetypes that specifies your clinical record (structure, constraints, terminology), I would recommend to create your Operational Templates (OPT) using the Ocean Template Designer. That is a big XML with all the referenced archetype semantics in one file (easy to handle).
After that, you have to make some design choices:
- Database technology
You can choose a relational, object based or document based technology. My preference is a mix of relational + some XML support. Most relational DBMS today support xml as a native datatype.
- Data model
There are two extreme models a) map the RM 1-1 to a DB model, b) use a key/value approach. For requirements that needs to query the hierarchy a) is better, but you'll have a lot of joins in relational DBMSs. For queries based on plain data b) is better but you'll need to have some logic if you want to build the hierarchy back from the k/v sets.
Why I mentioned the hierarchy? As you might notice, the openEHR Information Model has a tree structure, so is hierarchic by default, and that's because clinical information is hierarchical in nature.
What I did in my EHRServer was creating structured indexes in a relational DBMS. This approach sits in the middle of a) and b). I also use ORM tools (http://grails.org/doc/latest/guide/GORM.html) to automatically map object instances into tables.
One key aspect of the data model is to save the reference to the archetype that defines every data point, that can be done in the DB itself or using metadata to map archetype paths to a table/column.
- UI definition
You can create your UI by hand, or generate it from archetypes + templates. Either way you'll need some metadata to bind the fields on the UI to fields on archetypes. For this I use the field id and the archetypeId + path.
This helps me to bind input data from doctors into the openEHR Information Model, and with the right metadata this can be done in a generic way.
If you don't know about archetype Ids and paths, please read: http://openehr.org/releases/1.0.2/architecture/am/archetype_principles.pdf
I would recommend also the Architecture Overview: http://openehr.org/releases/1.0.2/architecture/overview.pdf
- Business logic
Binding data to your data model is part of the business logic, also validating that data. For validation I use the constraints that appear in the archetypes and operational templates. IF you have the archetype Id + path, you can get the constraint from the archetype and then you can evaluate that constraint against input data.
- Integration of previous components
Glue all the stuff together and you'll have: UI <-> logic <-> DB
Hope that helps.
回答3:
welcome to the world of openEHR :)
You may also find looking at open source examples useful - we have implemented an endoscopy reporting application using openEHR from persistence to automated GUI. A .Net winforms application in this case but uses MVC so I'd assume it wouldn't be too difficult to use Web or Mobile front-ends. What you won't find in openEHR at the moment is the means to model 'UI' together with data - therefore we used a 'hack' and exploited annotations feature to create some "GUI Directives" that are embedded into the clinical models.
Have a look at: http://gastros.codeplex.com
Also have written a couple 'papers' on implementation of openEHR if you like that sort of thing ;)
Atalag K, Yang HY, Tempero E, Warren JR. Evaluation of software maintainability with openEHR–a comparison of architectures. International Journal of Medical Informatics
Atalag K, Yang HY, Tempero E, Warren J. Model Driven Development of Clinical Information Sytems using openEHR. Stud Health Technol Inform. 2011;169:849–53.
Atalag K, Yang HY. From openEHR Domain Models to Advanced User Interfaces: a Case Study in Endoscopy. Wellington; 2010. Available from: http://www.hinz.org.nz/uploads/file/2010conference/P17_Atalag.pdf
Good luck! One last note - HL7 as some others have noted is for 'outside of systems' or for health information exchange - some have attempted to use RIM to build applications. openEHR exists for this purpose - so it is THE specifications to build EHR systems. The emerging FHIR standard from HL7 has similarities in terms of defining clinical data models - I also recommend to watch that space: We are hoping some sort of convergence will occur in the not so distant future hopefully ;)
回答4:
You might also want to have a look at
dev.ehrscape.com which is based on an underlying openEHR backend and
look at the GET composition call
You will see an example of JSONified openEHR data. This is a simplified version of 'canonical' openEHR data, but helps give you an idea of the genral structure
Other examples are at http://www.medvision360.com/medcloud/?lang=en, simialrly with an openEHR based data model
Here is a snippet of vital signs in json format...
{
"ctx":{
"language":"en",
"territory":"GB",
"composer_name":"Sr. Kristen George"
},
"nursing_vital_signs_observations":{
"vital_signs":[
{
"respirations":[
{
"any_event":[
{
"rate":[
{
"|magnitude":16,
"|unit":"/min"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"blood_pressure":[
{
"any_event":[
{
"systolic":[
{
"|magnitude":123,
"|unit":"mm[Hg]"
}
],
"diastolic":[
{
"|magnitude":102,
"|unit":"mm[Hg]"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"pulse":[
{
"any_event":[
{
"heart_rate":[
{
"|magnitude":93,
"|unit":"/min"
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
},
{
"indirect_oximetry":[
{
"any_event":[
{
"spo2":[
{
"|numerator":94,
"|denominator":100
}
],
"time":[
"2014-07-17T15:18:07.339+01:00"
]
}
]
}
]
}
],
"context":[
{
"setting":[
{
"|code":"233",
"|value":"secondary nursing care",
"|terminology":"openehr"
}
],
"start_time":[
"2014-05-22T15:18:07.339+01:00"
]
}
]
}
}
回答5:
You may find some help by looking at this work on GitHub https://github.com/ppazos?tab=repositories much of it is based around openEHR concepts.
In the world of multi-level knowledge modeling in healthcare there is also MLHIM. MLHIM grew out of experience with openEHR and is based directly on XML standards. www.mlhim.org and https://github.com/mlhim
回答6:
Records are compiled and transmitted in XML to other vendors or organizations. HL7 is used for sending messages such as lab orders to/from lab vendors with specific OBR and OBX.
I'm not sure what you are looking to do with your research - if you're building your own app/site, then I would suggest blue button plus. It is an initiative by the ONC and the js will parse most CCDA (XML document with patient info from EHR) documents. Look over the library on GitHub - https://github.com/blue-button/bluebutton.js
Most importantly, research the background (HITECH Act) and know the challenges (EHR interoperability). Go to HHS.gov and look over the information there. Also, you're going to need someone who knows medical terminology and codes (ICDs, CPTs, SNOMED, etc.) as well as a clinical advisor because you could have all the data in the world, but if you don't display it in a proper or meaningful way, it's essentially useless.
回答7:
If you are interested in the combination REST+openEHR (or other archetype-based EHR approaches like CIMI or ISO 13606) then you might find the approach described in http://www.biomedcentral.com/1472-6947/13/57 interesting, corresponding open source code in Java is available at https://github.com/LiU-IMT/EEE
More recent discussions regarding specifying/standardizing an openEHR REST API can be found at https://openehr.atlassian.net/wiki/display/spec/openEHR+REST+APIs
Having a standardized REST API for openEHR will enable end user applications to connect to openEHR backends from several different vendors/projects so that you do not need to spend so much time on storage & query.
回答8:
Simplified answer to your question:
- Data Model: use any platform which adhers openEHr Specs.
- Data Constraints: Use archetypes : can be defined in ADL or XML
- openEHR record instance: XML
- Database: any
Here is a openEHR record for blood glucose with clinical data encoded using LOINC:
<namespace>EHR</namespace>
<type>COMPOSITION</type>
</contribution>
<commit_audit>
<system_id>10aec661-5458-4ff6-8e63-c2265537196d </system_id>
<committer xsi:type="PARTY_IDENTIFIED">
<name>guest</name>
</committer>
<time_committed>
<value>2008-05-22T10:34:28</value>
</time_committed>
<change_type>
<value>creation</value>
<defining_code>
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_string>249</code_string>
</defining_code>
</change_type>
</commit_audit>
<uid>
<value>c7ff23f4-6ad2-4ff9-bedf-fb60be37666e::10aec661-5458-4ff6-8e63-c2265537196d::1
</value>
</uid>
<data xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="COMPOSITION" xmlns="http://schemas.openehr.org/v1" archetype_node_id="openEHR-EHR-COMPOSITION.report.v1">
<name>
<value>Blood glucose report</value>
</name>
<archetype_details>
<archetype_id>
<value>openEHR-EHR-COMPOSITION.report.v1</value>
</archetype_id>
<template_id>
<value>blood_glucose</value>
</template_id>
<rm_version>1.0.1</rm_version>
</archetype_details>
<language>
<terminology_id>
<value>ISO_639-1</value>
</terminology_id>
<code_string>en</code_string>
</language>
<territory>
<terminology_id>
<value>ISO_3166-1</value>
</terminology_id>
<code_string>AU</code_string>
</territory>
<category>
<value>event</value>
<defining_code>
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_string>433</code_string>
</defining_code>
</category>
<composer xsi:type="PARTY_IDENTIFIED">
<name>Some Labs, at some place</name>
</composer>
<context>
<start_time>
<value>2012-02-26T11:44:17+1000</value>
</start_time>
<setting>
<value>other care</value>
<defining_code>
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_string>238</code_string>
</defining_code>
</setting>
<other_context xsi:type="ITEM_TREE" archetype_node_id="at0001">
<name>
<value>other context</value>
</name>
</other_context>
</context>
<content xsi:type="SECTION" archetype_node_id="openEHR-EHR-SECTION.diagnostic_reports.v1">
<name>
<value>Blood Glucose</value>
</name>
<items xsi:type="OBSERVATION" archetype_node_id="openEHR-EHR-OBSERVATION.lab_test-blood_glucose.v1">
<name>
<value>Blood glucose</value>
</name>
<language>
<terminology_id>
<value>ISO_639-1</value>
</terminology_id>
<code_string>en</code_string>
</language>
<encoding>
<terminology_id>
<value>IANA_character-sets</value>
</terminology_id>
<code_string>UTF-8</code_string>
</encoding>
<archetype_details>
<archetype_id>
<value>openEHR-EHR-OBSERVATION.lab_test-blood_glucose.v1</value>
</archetype_id>
<template_id>
<value>Blood glucose</value>
</template_id>
<rm_version>1.0.1</rm_version>
</archetype_details>
<subject xsi:type="PARTY_IDENTIFIED">
<externalRef xsi:type="PARTY_PROXY">
<id >
<value>1.2.4.5.6.12.1</value>
<root >
<value>1.2.4.5.6.12.1</value>
</root>
</id>
<namespace>DEMOGRAPHIC</namespace>
<type>PERSON</type>
</externalRef>
<name>Patient Name</name>
<identifiers xsi:type="DV_IDENTIFIER">
<issuer>Some issuer id</issuer>
<assigner>Some Assignee</assigner>
<id>B5404149</id>
<type>null</type>
</identifiers>
</subject>
<protocol xsi:type="ITEM_TREE" archetype_node_id="at0033">
<name>
<value>Tree</value>
</name>
<items xsi:type="CLUSTER" archetype_node_id="at0039">
<name>
<value>Specimen details</value>
</name>
<items xsi:type="ELEMENT" archetype_node_id="at0040">
<name>
<value>DateTime received</value>
</name>
<value xsi:type="DV_DATE_TIME">
<value>2006-11-22T18:57:01</value>
</value>
</items>
<items xsi:type="ELEMENT" archetype_node_id="at0041">
<name>
<value>DateTime processed</value>
</name>
<value xsi:type="DV_DATE_TIME">
<value>2006-11-22T18:57:01</value>
</value>
</items>
</items>
</protocol>
<data archetype_node_id="at0001">
<name>
<value>data</value>
</name>
<origin>
<value>2006-11-22T18:57:01</value>
</origin>
<events xsi:type="POINT_EVENT" archetype_node_id="at0002">
<name>
<value>Any event</value>
</name>
<time>
<value>2006-11-22T18:57:01</value>
</time>
<data xsi:type="ITEM_TREE" archetype_node_id="at0003">
<name>
<value>Tree</value>
</name>
<items xsi:type="ELEMENT" archetype_node_id="at0005">
<name xsi:type="DV_CODED_TEXT">
<value>Glucose 1h^Post Meal</value>
<defining_code>
<terminology_id>
<value>LN</value>
</terminology_id>
<code_string>10449-7</code_string>
</defining_code>
</name>
<value xsi:type="DV_TEXT">
<value>Blood Glucose</value>
</value>
</items>
<items xsi:type="ELEMENT" archetype_node_id="at0004">
<name>
<value>Blood glucose</value>
</name>
<value xsi:type="DV_QUANTITY">
<magnitude>100</magnitude>
<units>mmol/l</units>
<precision>0</precision>
</value>
</items>
</data>
</events>
</data>
</items>
</content>
</data>
<lifecycle_state>
<value>completed</value>
<defining_code>
<terminology_id>
<value>openehr</value>
</terminology_id>
<code_string>532</code_string>
</defining_code>
</lifecycle_state>
来源：https://stackoverflow.com/questions/25449018/how-is-openehr-supposed-to-be-used