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 | |
| ADL/AOM 1.5 support | 2 | |
| 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 |
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, 1.5, ... | tool can read & write non-specialised test archetypes |
| Specialisation | ADL 1.4, 1.5, ... | tool can read & write specialised test archetypes with various features |
| Slots | ADL 1.4, 1.5, ... | tool can read archetypes containing slots |
| Templates | ADL 1.4, 1.5, ... | tool can read archetypes containing slot fillers, mandation, removal, etc |
| Terminology | ADL 1.4, 1.5, ... | 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
Commercialising the Platform