Most of the terminology expressed in healthcare are fixed bindings defined by standard committees through meticulous evaluation. Everything from status to type to disease has a code classification which is defined through some system.
FHIR defines this as CodeableConcept , Where you can select a code which is part of a CodeSystem , these concepts were introduced to allow multiple clients to work with the same data structure and application.
Care will implement CodeConcepts and CodeSystems in an abstracted manner and provide pluggable integrations with popular CodeSystems while allowing users to maintain their own CodeSystems if needed. This allows care to remain a true open source free software.
Because there are a lot of confusing terms, here is the actual definition of each of those terms
Code Indicates a value is taken from a set of controlled strings defined elsewhere. This is a unique to the system.
Coding represents a Code along with the system in which the code was taken from along with other metadata required to uniquely identify the code in the system.
CodeableConcept represents a value that is usually supplied by providing a reference to one or more terminologies or ontologies but may also be defined by the provision of text. Multiple Coding can exist for a single CodeableConcept
CodeSystem is the group of all codes under a common provider, ie all snowmed CT codes are under the snowmed system.
Codes can be bound with different strengths
**Required ****This means that the value is bound to be present in the set of options. This is required when business logic is dependent on the value. In Care, code bound with the Required strength cannot be changed via the client. It requires rebuilding or enhances the feature through plugs
Extensible If an option from the value set cannot be used, some other type of datatype can also be used to capture the data, maybe a note or some other coding system even. Care will use freeform text fields in this case.
Extensible These options have a fixed definition within the FHIR/HL7 system, but since they are not involved in any business logic and facilities may find it useful to add options to the set of values, Care will allow adding values to the option via plugs. Note that these values do not have a unique identity and the value will be lost during interoperability with other systems
Example These options are not explicitly defined, but they are part of some system. Different systems maintain and license their content in different ways, so it may not be ideal for Care to lock into one provider, instead Care will maintain an abstract implementation where the instance can add its own options. Care will maintain plugs that will integrate with major data providers which provide data for free for India to comply with license requirements. The abstract implementation might also implement search functionality, in this cases we will proxy filter requests to a terminology server and let it filter for us. Care plugs can also implement it themselves, all implementation of this is left to the plug to be figured out, Care expects data to be filtered as per HL7 FHIR spec.
Care will maintain an abstracted version of systems and define a default system called Care . This system will not contain any data and will expect the instance admin to create data ( we can create a command to populate some dummy data if needed ). API’s will be maintained to create codes under this system as per the FHIR spec. This is maintained for facilities that do not want to integrate any systems and work in a standalone manner. Note that Interoperability will be greatly hindered in this case.