Provide means for procurement and government to specify requirements.
Proposed approach: IHE
What openEHR 'profiles' are required? Initial notes...
Conformance | How tested |
---|---|
Versioning, audit and Contribution | |
Full RM support | Test for canonical XML, JSON for:
|
ADL/AOM 1.4 support | |
ADL/AOM 1.5 support | |
Service Interfaces / APIs | |
AQL | |
GDL |
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
|
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 |
Key areas:
Sigurd From (DIPS), mentioned technology levels from original specification diagrams in architecture overview.
Silje Ljosland (Bergen) mentioned:
Other areas that could be specified and tested:
Rules for connectathons