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 firstname.lastname@example.org
I look forward to combining all this and sharing with the community soon
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.
For Bahmni, I recall at one point some Big Functional List that was compiled and might be useful here. @jteich, is this something that can be shared?
Thank you, I have a copy of that one, very helpful
I think a good start would be doing a review of some of the papers published about EHR on https://www.ncbi.nlm.nih.gov/pubmed
For example, this article: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5703976/
“Open-Source Electronic Health Record Systems for Low-Resource Settings: Systematic Review” has a paragraph titled “Identification of Key Features”, maybe this could be useful:
- 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
Could you tell us more about this project?
@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!