# CMC Proposal

## Insights

*The volume of healthcare data is growing. According to RBC Capital Markets, about 30% of the world’s data is generated by the healthcare sector. Looking ahead to 2025, the compound annual growth rate of healthcare data is projected to hit 36%.*

## Design Principals

- **Focus on the 20% of requirements that satisfy 80% of the interoperability needs.**
- **Clear Boundaries:** Resources should have a clear boundary; one that matches one or more logical transaction scopes.
- **Meaningful Differences:** Resources should differ from each other in meaning, not just in usage (e.g., each different way to use a lab report should not result in a different resource).
- **Natural Identity:** Resources need to have a natural identity.
- **Common Use:** Most resources should be very common and used in many different business transactions.
- **General Support:** Resources should not be specific or detailed enough to preclude support for a wide range of business transactions.
- **Mutual Exclusivity:** Resources should be mutually exclusive; this is a very important consideration that helps to reduce redundancy and ambiguity.
- **Novel Content:** Resources should use other resources, but they should be more than just compositions of other resources; each resource should introduce novel content.
- **Logical Framework:** Resources should be organized into a logical framework based on the commonality of the resource and what it links to.
- **Sufficient Size:** Resources should be large enough to provide meaningful context; resources that contain only a few attributes are likely too small to provide meaningful business value.
- **Reflect General Usage:** Resources should reflect general usage:
- If most systems treat something as a single concept, that suggests a single resource; if most systems treat something as distinct concepts, then that suggests multiple resources.
- If two different uses of a "resource" would result in wildly different interpretations of what constitutes "core," then that suggests two resources might be appropriate.
- **Resource Bias:** There is a bias towards fewer resources rather than more.

## Descriptions of the layers in the framework

### Foundation Resources

Foundation resources are the most rudimentary, foundational resources. They are often used for infrastructural tasks. Although not prohibited, they are not always referenced by other resources.

### Base Resources

Layer two consists of base resources. These are often the leaf nodes of a resource graph, meaning they are often referenced by other resources, but don't typically reference other resources themselves. These resources are typically the most commonly used, and therefore require the highest degree of consistency and architectural rigor. Governance is greatest for resources in layers one and two.

### Clinical Resources

Layer 3 includes the resources that are clinical in nature but are also very common across many use cases. This includes resources for clinical observations, clinical treatment, care provision, and medications. These resources can be used by themselves, but typically build on the resources in layer two. For example, an observation resource will reference the patient resource from layer two. These resources are also frequently contextualized when they are referenced by resources in layers three, four, and five.

### Financial Resources

Layer four is dedicated to financial resources. Logically, financial resources build on clinical and base resources. For example, a billing resource will reference clinical events and activities as well as base resources like a patient.

### Specialized Resources

In layer five, we find more specialized resources for less common use cases. These resources almost always reference resources in lower layers. Given that FHIR places priority on satisfying the most common use cases, there are fewer resources in this layer.

### Resource Contextualization

Layer 6 does not contain resources. However, it does extend the composition framework made up by the first five layers of resources. Layer 6 includes profiles and graphs. Profiles are used to extend, constrain, or otherwise contextualize resources for a given purpose. Graphs are compositions of resources, or webs of resources, that contain attributes of their own.

### Concepts
- **Resources**
- Patient
- Practitioner
- Medication
- Observation
- Encounter
- **Interactions**
- Create
- Read
- Update
- Delete
- Search
- History
- **Exchange Formats**
- XML
- JSON
- Turtle

### Components
- **StructureDefinition**
- Resource Profiles
- Extension Definitions
- **ValueSet**
- Code Systems
- Concept Maps
- **OperationDefinition**
- Operations
- Parameters

### Implementation
- **Servers**
- RESTful API
- Messaging
- Services
- **Clients**
- Web Applications
- Mobile Applications
- Desktop Applications

### Integration
- **HL7 Standards**
- v2 Messaging
- v3 Messaging
- CDA Documents
- **IHE Profiles**
- Patient Identifier Cross-referencing
- Consistent Time
- Audit Trail and Node Authentication

### Security and Privacy
- **Authentication**
- OAuth2
- SMART on FHIR
- **Authorization**
- Access Control
- Role-Based Access Control
- **Data Privacy**
- De-identification
- Encryption
- Consent Management

### Use Cases
- **Clinical**
- Electronic Health Records
- Clinical Decision Support
- Remote Patient Monitoring
- **Administrative**
- Billing and Claims
- Appointment Scheduling
- Resource Management
- **Research**
- Clinical Trials
- Population Health Studies
- Genomic Data Analysis

### Standards and Compliance
- **Regulatory Requirements**
- HIPAA Compliance
- GDPR Compliance
- **Certification**
- EHR Certification
- Interoperability Certification
- **Testing and Validation**
- Conformance Testing
- Interoperability Testing

### Limitations and Challenges
- **Data Complexity**
- Data Variability
- Data Volume
- **Adoption Barrier**
- Cost
- Technical Expertise
- Stakeholder Resistance
- **Interoperability Issues**
- Semantic Interoperability
- Syntactic Interoperability
- Organizational Interoperability