EXPAND - Interoperability Asset Register > View asset : "OpenNCP"
Asset register descriptors
These descriptors provide basic information about the publishers of an interoperability asset and how it may be accessed.
1. Name: label of the asset given by its creators.
OpenNCP
2. Use cases supported: one or more interoperability use cases
1. CEF RELATED 2015
1.1. Patient summary, chronic diseases, continuity of care
1.2. ePrescription
2. WIDER CROSS_BORDER USE CASES
none selected
3. Asset type: category of asset.
A. General
2. Methodology
B. Legal, organisational
none selected
C. Technical, semantic
25. Engineering artefact (software)
26. Source code
4. Scope: the objective or purpose that this asset serves, in support of interoperability.
Develop Open Source Components (OpenNCP) that can be adopted by Participating Nation, to build their local implementation of the epSOS NCP
5. Source initiative: the organisation, project or program that has created this asset.:
5.1 Full name:
epSOS - epSOS - Smart Open Services for European Patients
5.2 Short name:
epSOS
5.3 Website:
6. Current custodian (curator): the organisation that currently holds this asset from a legal and intellectual property ownership perspective.
6.1 Name:
OpenNCP Community
6.2 Organisation:
OpenNCP Community
6.3 Designation:
OpenNCP Community
6.4 Internal contact: an email address and/or telephone number
Email:
Phone:
7. Version number: an increment number for serial updates to the entry in the register for this asset.
2.1.1 (2.1.1 Release Changelog and Notes)
8. URL of hosting organisation: the web link to the organisation which is holding an available copy of this asset.
9. Publicly accessible contact information:
Email:
Phone:
Quality and reuse descriptors
These descriptors provide detailed information about how the asset may be re-used, and how its suitability for intended use may be evaluated. These descriptors do not formally assert the quality of an asset to any given quality standard, but provide the means by which a potential user can form an opinion on whether its quality is sufficient for intended purpose.
12. Usage supported: A short textual description to provide more precise information about the interoperability use case(s) supported by this asset.
Patient Summary (PS):
ePrescription/eDispensation (eP/eD):
Patient Access (PAC)
Health Care Encounter Report (HCER):
Medication Related Overview (MRO):
13. Domain coverage: the areas of healthcare interoperability for which this asset has been developed, possibly specifying the care settings, professional groups, specialties and/or scenarios for which it has been developed and validated in use.
Unplanned care.
14. Targeted user group: the intended uses of this asset, such as clinicians, patients, service managers, procurers, ICT staff, lawyers.
Clinicians and Patients
15. Evidence used: a summary of the clinical evidence, informatics evidence, standards or other published good practices that have been used when designing this asset, and to which it may therefore conform.
IHE Profiles, HL7-CDA, Master Value Catalogue (clinical terminologies)
16. Consultation process: stakeholder engagement activities that were undertaken to complement any published evidence, statements about the transparency and inclusivity of these engagement processes, and an indication of when and where these activities took place.
Answer text....
17. Quality processes used: Quality assurance practices that have been used when developing the asset, such as ISO 9000 or other recognised methodologies, or describing more informal processes of internal quality assurance that we used to assess the correctness of the asset.
Answer text....
18. Technical design:a technical description of the asset if it is a technical specification or implementation (such as the format, programming languages or other design characteristics used), if it has an open (service oriented) architecture, if there are published interfaces, and if terminology bindings are accessible and configurable.
Answer text....
19. Conformance to standards: which relevant standards were used, and if conformance to them has been verified).
IHE Profiles, HL7-CDA, Master Value Catalogue (clinical terminologies: SNOMED CT, LOINC, ICD-9, ICD-10, etc)
20. Domain completeness: if this asset covers all or only part of an intended domain (perhaps due to resource constraints)).
Answer text....
21. Technical completeness: if this asset is a final version, an advanced prototype, work in progress, developed but untested etc.")
Answer text....
22. Relevant security features: efforts that have been made to ensure that this asset will contribute appropriately to the protection of privacy and the application of relevant information security measures within anticipated deployment environments, if any specific privacy protection measures have been included, and if a risk assessment has been conducted.
Answer text....
23. Alignment with other relevant assets: any other interoperability assets with which this asset is deliberately intended to be used (e.g. as part of one or more asset bundles) or if other steps have been taken to ensure that this asset can support co-operative use with other assets that would normally be needed to address the targeted use case and which may have been developed by other organisations.
Answer text....
24. Link to other assets: one or more references to other entries in this asset register, to other assets that are intended to be used alongside this asset
No assets has been selected.
Answer text....
25. Extensibility: to what extent this asset may in future be extended by others, potentially to incorporate additional features, to extend any internal vocabularies, or to incorporate language translations.
Answer text....
26. Endorsements: any organisations which, during the development or subsequently, have indicated their support of this asset or given endorsement of its use within given jurisdictional or organisational domains, such as professional bodies, governments etc.
Answer text....
27. Reliability of access:if the asset presently is being held and managed by a recognised organisation, the provisions made for its reliable and continual access.
Answer text....
28. Licensing: the IP & licensing arrangements (including costs) that need to be agreed to by a potential future user.
Answer text....
29. Available formats: in which natural languages and in what publication or technical formats may the asset be obtained.
Answer text....
30. Viable business model(s), market: any assessments that have been made to establish that the asset contributes business value to the achievement of the targeted interoperability use cases, and what evidence exists for the size of the actual and potential market.
Answer text....
31. Adoption: evidence of the successful implementation and adoption of this asset; any critical enablers and factors affecting successful adoption that future users should also take into account.
Answer text....
32. Communities of use: if there are established communities of use which provide an indication of market uptake and may also act as a supporting community to guide future users.
Answer text....
33. Impact: any evidence of business impact from the use of this asset, including any clinical and economic evaluations.
Answer text....
34. Documentation: extent of the available documentation, if this includes an indication of any outstanding efforts required to complete this asset in readiness for large-scale use, any indication of the anticipated annual maintenance effort, any documented plan for intended evolution of this asset (to fund its maintenance and potentially to enlarge its scope and scalability) if a formal version management process is in place for this asset
Answer text....