openEHR 2014 Roadmap - Product and Market
Conformance
Requirement
Provide means for procurement and government to specify requirements.
Proposed approach: IHE
- publish 'profiles'
- vendors come to connectathon and demonstrate interop for profile A, B, C etc
Profiles - areas of conformance
What openEHR 'profiles' are required? Initial notes...
Conformance | Level | How tested |
---|---|---|
Versioning, audit and Contribution | 1 | |
Full RM support | 1 | Test for canonical XML, JSON for:
|
ADL/AOM 1.4 support | 1 | |
Templating support | 1 | |
Archetype-based data validation | 1 | |
Basic Service Interfaces / APIs
| 1 | |
virtual EHR API | 2 | |
Demographic API | 2 | |
Knowledge API | 2 | |
AQL | 2 | |
GDL | 3 | |
ADL/AOM 2 support | 3 |
A possible grid based for conformance based on RM modules
RM module | Canonical | Archetype support | Template support | Queriable | API support | Terminology |
---|---|---|---|---|---|---|
EHR (COMPOSITION, SECTION, ENTRY) | XML JSON binary other | solution supports archetypes for any content based on this part of RM | solution supports templates for any content based on this part of RM | solution supports queries against data based on archetypes and this part of RM | solution has APIs for content based on this part of RM | solution supports querying that uses / includes external terminologies; which terminologies supported |
Demographic | ||||||
EHR Extract | ||||||
Core (date types, structures, identifiers) | which data types |
Conformance of content model tooling
Model feature | Level | Test criteria |
---|---|---|
Basic archetype | ADL 1.4, 2, ... | tool can read & write non-specialised test archetypes |
Specialisation | ADL 1.4, 2, ... | tool can read & write specialised test archetypes with various features |
Slots | ADL 1.4, 2, ... | tool can read archetypes containing slots |
Templates | ADL 1.4, 2, ... | tool can read archetypes containing slot fillers, mandation, removal, etc |
Terminology | ADL 1.4, 2, ... | tool can support models containing terminology ref-sets |
Conformance for Clinical Decision Support components / solutions
Key areas:
- tools
- authoring
- execution
Conformance by Solution 'stack' level
Sigurd From (DIPS), mentioned technology levels from original specification diagrams in architecture overview.
Silje Ljosland (Bergen) mentioned:
- flexible / customisable UI
- mobile device support
Other Conformance areas
Other areas that could be specified and tested:
- Scalability: volumetrics, transaction processing rates
- integration - demonstrate systems can talk to each other using:
- APIs
- EHR Extract
- 'openFIRE'
Conformance Testing - Connectathons
Rules for connectathons