As explained in the original purpose doc, Cumulus aims to provide a centralized way for sharing health records in a way that a diversity of systems (a.k.a. consumers) can pull & push patient data in an organized way, thus keeping the health records updated and relevant throughout different healthcare providers and the patient itself.
TL;DR; Digital health information should follow the patient throughout modern healthcare providers, and not the other way around
- Persistance: Central repository
- NoSQL (mainly) data persistance for flexibility & max compatibility w/ other backend / client consumers
- API Server:
- Data Exchange: REST/GraphQL service
- Auth: OAuth 2.0 (or similar)
- Transformation Layer
- Can be on the API or Client-side (ex. Ember-Data adapter)
- To expose/accept data in standard formats:
- Nimbo X, Cirrus custom formats
- Health Level Seven
- etc... (see purpose doc)
+--------+ +--------+ +--------+
| | | | | |
| Client +-->| Server | | Client |
| | | | | |
+--------+ +-----+--+ +--+-----+
^ | | ^
| | | |
| v v |
.---+------------+--------------+-----.
| C | Transformation Layer |
| U +---------------------------------+
| M | |
| U | API Server |
| L | |
| U +---------------------------------+
| S | NoSQL DB |
'---+---------------------------------'
*Note: The aforementioned components, specially at the backend, doesn't have be a monolithic bundle at all, as they can can be decoupled microservices deployed in a distributed way. Examples of decoupled/distributed architectures:
- JAMStack
- BlockStack
- OpenStack
- Serverless
- TorusCLI (distributed secrets)
- Torus Distributed Storage (not related to previous one)
Document-based JSON (NoSQL) databases feel a natural fit for the health record use-case:
These documents are self-describing, hierarchical tree data structures which can consist of maps, collections, and scalar values. The documents stored are similar to each other but do not have to be exactly the same.
Alternatively Column-family databases might also be useful, regarding performance and data-sharding:
Column families are groups of related data that is often accessed together
For a Cumulus prototype, a widely-use, general-purpose document-based databas would be better suited, as stated:
- Document databases are generally useful for content management systems, blogging platforms, web analytics, real-time analytics, ecommerce-applications. We would avoid using document databases for systems that need complex transactions spanning multiple operations or queries against varying aggregate structures.
- Column family databases are generally useful for content management systems, blogging platforms, maintaining counters, expiring usage, heavy write volume such as log aggregation. We would avoid using column family databases for systems that are in early development, changing query patterns.
Other sources:
- http://basho.com/resources/nosql-databases/
- https://www.digitalocean.com/community/tutorials/a-comparison-of-nosql-database-management-systems-and-models
- https://www.mongodb.com/nosql-explained
Related: https://github.com/ecaresoft/ecs-meta/pull/32
- MongoDB: https://www.mongodb.com/
- CouchDB: http://couchdb.apache.org/
- Amazon DynamoDB: https://aws.amazon.com/dynamodb/
- OrientDB: http://orientdb.com/orientdb/
- Apache Cassandra: http://cassandra.apache.org/
- GraphQL: http://graphql.org/code/#server-libraries (Node, Ruby, Elixir, Java, etc...)
- Falcor: http://netflix.github.io/falcor/
- GraphQL: http://graphql.org/code/#graphql-clients
- Apollo Data: http://www.apollodata.com/
- Relay: https://facebook.github.io/relay/
- Falcor: http://netflix.github.io/falcor/
Initially a simple format based on CCR standard could be implemented, containing the main 6 sections (see @luissifu comment below):
- Header
- Patient Identifying Information
- Patient Financial and Insurance Information
- Health Status of the Patient
- Care Documentation
- Care Plan Recommendation
In later versions, full CCR-compatible records should be available, as it is the basis for compatibility with other standards:
____________
.-----------. \ \....................... (CCR-compatible systems)
/ CCR \ \ XML \ __________
( )---->) Transf. ) \ XSLT \
\ {JSON} / / Layer /---->/ Layer /...... (CCD/HL7 FHIR CDA systems)
'-----------' /___________/ /_________/
\
............................................... Other systems (Nimbo X, ...)
FHIR® – Fast Healthcare Interoperability Resources (hl7.org/fhir) – is a next generation standards framework created by HL7. FHIR combines the best features of HL7's v2 , HL7 v3 and CDA product lines while leveraging the latest web standards and applying a tight focus on implementability.
FHIR solutions are built from a set of modular components called "Resources". These resources can easily be assembled into working systems that solve real world clinical and administrative problems at a fraction of the price of existing alternatives. FHIR is suitable for use in a wide variety of contexts – mobile phone apps, cloud communications, EHR-based data sharing, server communication in large institutional healthcare providers, and much more.
https://www.hl7.org/fhir/summary.html
For the MVP, patient id would be simple, matching the SSN, CURP or similar. Later on more complex matching can be implemented.
An UPSERT operation should be done when Creating or Updating a record, using it's identityNumber as primary key.
A revision number should be included in every record's header, being a serial number, or even better a hash fingerprint that uniquiley represent a changeset.
A polling mechanism should be available so the consumer can figure out if it has the latest revision of the record.
+------+ +-----+
| | Patient 1, Revision 3 | |
| N +---------------------->| C |
| i | | u |
| m | | m |
| b | OK, latest rev: 3 | u |
| o |<----------------------| l |
| | | u |
| X | | s |
| | | |
+------+ +-----+
--------------------------------------
+------+ +-----+
| | Patient 1, Revision 3 | |
| N +---------------------->| C |
| i | | u |
| b | {NEW DATA} (Rev: 4) | u |
| o |<----------------------| l |
| o | | l |
| | | u |
| X | | s |
+------+ +-----+For the MVP this wouldn't be in the scope. Nevertheless it's important to consider a robust enough data model that can handle edit history.
Think of it as an intermediary point between Google Docs & Git.
Ideally data syncing between Cumulus and consumers should be automatic, with notifications for the changes made since last visit (ex. new medical conditions, procedures, etc).
See:
For the MVP this can be triggered manually for PoC purposes.
Siento que aun falta definir o al menos empezar a establecer una estructura para el archivo donde se va a guardar el historial del paciente, ie algo como lo que menciona jorge, el CCR.
El CCR tiene 6 secciones principales
De las cuales nos podemos basar para sacar algo que este cercano a esto y que tambien sea posible convertirlo al CCR para mayor portabilidad. Uno de los formatos que arroje el API puede ser xml, para que de ahi saque el CRR. Ejemplo.
Como nitpick, pero cambiare todo el wording de "paper", se presta a malinterpretacion como si tuvieramos un paper (research) en el cual nos estariamos basando en vez de un dropbox paper.