The core features of the EHRServer the compliance with the the openEHR standard. So if you are planning to use the EHRServer, it is good to know a little about openEHR to get the most out of the EHRServer. Here we go!
openEHR is an open standard that specifies all the architectural components needed to create health information systems that are interoperable, higly maintainable, and very flexible. The architecture has 3 main components: information, knowledge and services. The specifications are maintained by the openEHR Foundation, though it's Specifications Program.
The main component of the openEHR specs is the Information Model. It defines the complete hierarchy of data structures, from the EHR to the individual data types. The IM is very generic, flexible and relatively small, and it allows to represent different data structures for a virtually inifinite number of scenarios.
The second component is the Knowledge Model, that is composed by the Archetype and Template Models. openEHR Archetypes are semantic definitions of clinical concepts that can be used to record clinical information. For example, there are Archetypes for Blood Pressure, Heart Rate, Diagnosis, Lab Order Request, Medication Prescription, Triage, Procedure, etc. You can find a lot of Archetypes in the international Clinical Knowledge Manager (CKM). Archetypes define the concept, the purpose and context of use, the data structure to record information about that concept, data constraints that allow data validation, translations to different languages, and references to standard terminologies. Yes, openEHR takes advantage of terminologies like SNOMED CT, ICD10, CIAP-2, etc.
Archetypes represent individual concepts. When we want to create the definition of a full clinical document in openEHR, we create a Template. Templates use Archetypes, but you can specify which parts of each referenced Archetype should be included in the Template and which parts should not. In a way, Templates are like huge Archetypes, but the purpose is different. Also Templates allow only one language, so to define documents for different languages, you need to create different Templates.
The Service Model is formally under construction. It's architectural components are defined, and most of them are part of the current openEHR implementations, but there is no normative specification. We have services around: EHR, Demographics, Terminology, Audit, Identity, Security, Knowledge, Notification and Workflow. One of the specs related to Services that is almost complete is the openEHR REST API specification. When this specification is realeased, we plan to implement a compliant REST API. For now the EHRServer REST API is very close to the openEHR REST API specs.
For more information check the openEHR Specifications.
openEHR has a great international community composed by informaticians and clinicians from around the globe, from Uruguay to Japan, from Spain to Australia.
There are a set of open and free tools that are used a lot to work with openEHR. Among these tools, you can find:
Find more info about the tools here.