Hi all, I’m compiling a comprehensive EHR feature list.
Essentially, I want to outline (in rather granular detail) every feature require for a full service awesome EHR.
Then share that back to the OpenMRS community, and get help filling in the gaps that are missing. This step will be helpful in understanding how to build common components.
Please share if you have any EHR feature lists. Such as
EHR feature wish lists
EHR bug lists
EHR technical specification lists
EHR user stories lists
EHR user request lists
EHR deployment application settings lists
EHR user role lists
EHR settings lists
EHR clinical domains, diseases, condition lists
EHR reporting requirements lists
EHR database structure lists
EHR configuration settings lists
EHR modules lists
Literally anything related to EHR functionality would be helpful.
Please send to gschmidt@ampath.or.ke
I look forward to combining all this and sharing with the community soon
Note:
Please do not share any proprietary or confidential EHR specification documentation.
Please indicate in your email if I can share your document publicly, or if it can only be used to contribute to the aggregated master EHR feature list.
Integrated applications referring to the type of subsystems that are integrated in each solution
Configurable reports, general report templates may be generated by an end user, without programming skills
Custom reports, specific report templates can be created by a user with basic programming skills
Custom forms allow making a form template to gather patient data or other clinical information
Interoperability, ability to exchange data with other applications (it includes the support for standards such as Health Level-7 [HL7], Fast Healthcare Interoperability Resources [FHIR], and Digital Imaging and Communications in Medicine [DICOM])
Coding systems, referring to the utilization of medical terminology classification, such as SNOMED (Systematized Nomenclature of Medicine) or International Classification of Diseases (ICD)-10
Authentication methods enable users to access systems without credentials by using the authentication from third-party application (eg, single sign-on, lightweight directory access protocol [LDAP])
Patient portal can be accessed by patients to consult their own records
Access control model, management of users’ access, roles, and permissions
Cryptographic features refer to applying security techniques to conceal patient data
Flexible data model can cope with various and dynamic data characteristics
Offline support, still operating on the client side, when disconnected from the server
Web client, the application can be accessed through a common Web browser
Native client, has a client that runs natively on a specific desktop platform (eg, in Windows or Linux)
Other clients refer to more than one client version to cope with hardware limitations
Code-based language, programming language used for system’s source code (eg, Java)
Development activity refers to how often the software is updated and to the developers’ support
Software modularity refers to software engineering quality, namely, how manageable the system is
User interface refers to the usability of the system and how the user interface is perceived by end users
Community support includes discussion forum activities and community contributions such as translation of user interface to other languages
Customization, how easy modifications are without rewriting the core code of a system to reach established requirements
@mseaton, here is a link to the “Big Functional Outline” I had drafted for Bahmni – it’s available under om.rs/drive :
@maciej, thanks for the great link. @gschmidt and I, along with several others who met about this in Nairobi, are working to outline strategies to foster growth of OpenMRS applications and modules that solve several needs – in particular, that (a) can be adopted by end-user sites that do not have their own developer base, (b) make use of reusable functional components for simplicity and consistency and sharing and speed of development, and (c ) fit into a fairly broad schema of clinical/administrative application needs, tool types, healthcare environments and user types so it’s easier to do (a) and (b). We are doing some early visioning of what this looks like, and will share that soon and often, as we know this endeavor could use a lot of input!