List of every EHR feature ever needed


(Gregory Schmidt) #1

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.

Thanks!


(Mike Seaton) #2

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?


(Gregory Schmidt) #3

Thank you, I have a copy of that one, very helpful


(Maciej Neumann) #4

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:

  1. Integrated applications referring to the type of subsystems that are integrated in each solution
  2. Configurable reports, general report templates may be generated by an end user, without programming skills
  3. Custom reports, specific report templates can be created by a user with basic programming skills
  4. Custom forms allow making a form template to gather patient data or other clinical information
  5. 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])
  6. Coding systems, referring to the utilization of medical terminology classification, such as SNOMED (Systematized Nomenclature of Medicine) or International Classification of Diseases (ICD)-10
  7. 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])
  8. Patient portal can be accessed by patients to consult their own records
  9. Access control model, management of users’ access, roles, and permissions
  10. Cryptographic features refer to applying security techniques to conceal patient data
  11. Flexible data model can cope with various and dynamic data characteristics
  12. Offline support, still operating on the client side, when disconnected from the server
  13. Web client, the application can be accessed through a common Web browser
  14. Native client, has a client that runs natively on a specific desktop platform (eg, in Windows or Linux)
  15. Other clients refer to more than one client version to cope with hardware limitations
  16. Code-based language, programming language used for system’s source code (eg, Java)
  17. Development activity refers to how often the software is updated and to the developers’ support
  18. Software modularity refers to software engineering quality, namely, how manageable the system is
  19. User interface refers to the usability of the system and how the user interface is perceived by end users
  20. Community support includes discussion forum activities and community contributions such as translation of user interface to other languages
  21. 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?


(Jonathan Teich) #5

@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!